Draft 


AD-A263  443 

''"UiWIdlMlfllli 

ill!  ill 


Department 

of 

Defense  DTIC 

SELECTE 

APR2  61993  I  I 

E  ^ 

Electronic  Data 
Interchange  (EDI) 
Convention 


ASC  X 1 2  Transaction  Set  824 
Application  Advice 
(Version  003010) 


DL203LN6 


January  1993 


93-08755 


BASELINE  AS  OF:  JANUARY  29,  1993 


.^Ar>nTi 


mUMUN  STA' 


Approved  fot  public  relfli 
DiatributifflS 


DEPARTMENT  OF  DEFENSE  APPLICATION  ADVICE 

DRAFT  IMPLEMENTATION  CONVENTION  824.00301 0DoD_ 


Accesion  For 

' 

NTIS 

CRA&I 

W - 

OTIC 

TAB 

U'. announced 

□ 

Justification 

By, 

Dist,  lb 

I - 

ution/ 

1 

Availability  Codes 

Dist 

Avail 

ind/or 

Spc 

cial 

_ Draft 

Department 

of 

Defense 

DoD 

Electronic  Data 
Interchange  (EDI) 
Convention 

ASC  XI 2  Transaction  Set  824 
Application  Advice 
(Version  003010) 


.^c 


This  document  was  piepared  by  the  Logistics  Management  Institute  for  the  Defense  Logistics  Agency  under 
Task  DL2Q3.  The  task  was  performed  under  Contract  MDA903-9(VC-0006  wHk  the  Department  of  Defense. 
Permission  to  quote  or  reproduce  any  part  of  this  document  except  for  Govemntent  purposes  must  be 
obtained  from  the  Department  of  Defertse  Executive  Agent  for  Electronic  Commeroe/El^ronic  Data 
Interchange/Protection  of  LogistioUrtdassified/Seruitive  Systems. 


Executive  Agent  for  EC/ EDI /PLUS 
Defense  Logistics  Agency 
Cameron  Station 
Alexandria,  VA  22304-6100 


BASELINE  AS  OF:  JANUARY  29.  1993 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


TABLE  OF  CONTENTS 

1.0  INTRODUCTION .  1.01 

1.1  PURPOSE  OF  THE  CONVENTION  ....  1.0.1 

1.2  SCOPE  . 1.0.1 

1.3  RESPONSIBLE  ENTITY  . 1.0.1 

1.4  HOW  TO  USE  THE  IMPLEMENTATION 

CONVENTION . 1.0.2 

1.4.1  Conventions,  Standards,  and  Guidelines  .  .  1.0.2 

1.4.2 Documentation  of  Conventions . 1.0.3 

2.0  MAINTENANCE . 2.01 

2.1  MAINTAINING  COi  VENTIONS . 2.0.1 

2.2  VERSION/RELEASE  TIMING . 2.0.1 

3.0  DoD  CONVENTIONS  FOR  USING  ASC  X12 

TRANSACTION  SETS  3.01 

3.1  INTRODUCTION . 3.0.1 

3.2  CONTROL  SEGMENTS  . 3.0.1 

3.2.1  Description  of  Use . 3.0.2 

3.2.2Control  Segment  Specifications  . 3.0.5 

3.3  EXAMPLE  OF  CONVENTION  USE  ....  3.0.15 

3.4  DoD  CONVENTION  . 3.0.19 

4.0  ASC  X  12  FORMS .  4.01 

5.0  GLOSSARY . 5.01 

5.1  X12  GLOSSARY  . 5.0.1 

5.2  DoD  GLOSSARY . 5.0.6 


BASEUNE  AS  OF:  JANUARY  29, 1993 


iii 


DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


1.0  INTRODUCTION 

This  chapter  explains  the  purpose  of  the  convention,  the  scope  of 
the  guidance,  and  provides  an  explanation  of  how  to  use  the 
convention. 

1.1  PURPOSE  OF  THE  CONVENTION 

The  convention  provides  general  guidance  on  the  implementation 
of  American  National  Standards  Institute  (ANSI)  Accredited  Stand¬ 
ards  Committee  (ASC)  XI2  electronic  data  interchange  (EDI) 
standards  within  automated  information  systems  (AIS)  and  infor¬ 
mation  interchange  procedures  that  require  the  collection,  report¬ 
ing,  and/or  exchange  of  data  needed  to  perform  defense  missions. 

1.2  SCOPE 

The  guidance  is  provided  for  two  components.  First,  it  may  be 
used  by  organizational  elements  of  the  DoD  community.  It  may 
also  be  useful  to  organizations  external  to  DoD  that  exchange  data 
with  the  DoD  community  in  the  course  of  their  business  relation¬ 
ships. 

The  DoD  community  encompasses  the  Military  Services,  Organiza¬ 
tions  of  the  Joint  Chiefs  of  Staff,  Unified  and  Specified  Commands, 
Office  of  the  Secretary  of  Defense,  and  the  Defense  agencies.  (That 
community  is  collectively  referred  to  as  the  DoD  Components.) 

Organizational  entities  external  to  DoD  include  (a)  non-Govem- 
ment  organizations,  both  commercial  and  nonprofit;  (b)  Federal 
agencies  of  the  United  States  Government  other  than  DoD; 
(c)  local  and  state  governments;  (d)  foreign  national  governments; 
and  (e)  international  government  organizations. 

The  draft  convention  published  in  this  document  is  for  trial  use 
and  comment.  DoD  Components  must  submit  to  the  DoD  EDI 
Executive  Agent  (EA)  their  data  requirements  that  are  not  covered 
in  the  conventions  as  soon  as  possible,  as  indicated  in  Chapter  2.0, 
Section  2.1. 

1.3  RESPONSIBLE  ENTITY 

The  Defense  Logistics  Agency  (DLA)  is  DoD’s  Executive  Agent 
for  implementing  and  maintaining  Defense-wide  programs  for 
(a)  EDI  in  accordance  with  DepSecDef  memorandum  of  May  24, 
1988,  Subject;  Electronic  Data  Interchange  of  Business-Related 
Transactions:  and  (b)  Protection  of  Logistics  Unclassified/Sensi- 
tive  Systems  (PLUS)  in  accordance  with  Assistant  Secretary  of 
Defense  (Production  and  Logistics)  [ASD(P&L)]  memorandum  of 
November  21,  1989,  Subject:  Production  and  Logistics  Task 
Group  for  Data  Protection.  Publication  of  these  conventions  is 
based  upon  this  authority.  See  Chapter  2.0  Maintenance,  Section  2.1 
for  office  point  of  contact 


1.4  HOW  TO  USE  THE  IMPLEMENTATION 
CONVENTION 

The  main  topics  and  structures  of  this  document  conform  to  the 
EDI  Implementation  Reference  Manual  Guidelines  document  that 
was  developed  by  a  task  group  of  the  subcommittee  on  education 
and  implementation  of  the  ASC  X12.  The  purpose  of  having 
agreed-upon  topics  and  structure  is  to  facilitate  reference  by  the 
many  industry  and  DoD  personnel  who  are  involved  in  implement¬ 
ing  the  uniform  standards  for  electronic  interchange  of  business 
transactions. 

1.4.1  Conventions,  Standards,  and  Guidelines 

The  terms  conventions,  standards,  and  guidelines  are  used 
throughout  the  document  and  are  defined  as  follows: 

•  Conventions  are  the  common  practices  and/or  interpretations 
of  the  use  of  ASC  X12  standards.  Conventions  define  what  is 
included  in  a  specific  implementation  of  an  ASC  X12  standard. 

•  Standards  are  the  technical  documentation  approved  by 
ASC  X12;  specifically,  transaction  sets,  segments,  data  ele¬ 
ments,  code  sets,  and  interchange  control  structure.  Standards 
provide  the  structure  for  each  ASC  X12  document. 

•  Guidelines  are  instructions  on  the  use  of  EDI.  They  provide 
additional  information  to  assist  in  conducting  EDI.  Guidelines 
are  intended  to  provide  assistance  and  should  not  be  your  sole 
source  of  information. 

1 .4.1 .1  Who  Develops  the  Conventions? 

Conventions  result  from  a  joint  effort  between  business,  technical, 
and  EDI  ASC  X12  standards  experts.  The  business  data  require¬ 
ment  is  defined,  a  transaction  set  is  selected,  and  the  data  require¬ 
ment  is  then  identified  with  data  elements  in  the  transaction  set. 
A  convention  is  usually  developed  before  any  computer  EDI  sys¬ 
tems  development  work  and  serves  as  a  design  document  when  the 
development  process  begins. 

1 .4.1 .2  Why  Use  a  Convention? 

To  create  an  ASC  X12  transaction,  a  user  must  know  the  data 
requirements,  understand  the  ASC  X12  standard,  and  be  able  to 
use  that  information  to  develop  an  interface  program  between  the 
computer  application  and  the  ASC  X12  translator.  The  necessary 
information  to  perform  this  task  is  contained  in  the  convention 
document.  Users  who  follow  the  convention  will  create  a  transac¬ 
tion  set  that  all  DoD  users  understand. 

1 .4.1 .3  Who  Needs  a  Convention? 

System  analysts  and  application  programmers  who  plan  to  create 
or  read  ASC  X12  transactions  use  a  convention  to  aid  in  interface 
software  design.  Hie  convention  will  help  the  programmer  and 
analyst  identify  where  their  application  data  requirement  should  be 
carried  in  an  ASC  X12  transaction  set. 
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1. 4.4.4  Can  I  Develop  a  Convention? 

Conventions  already  exist  for  some  of  the  most  common  business 
practices.  Copies  of  existing  conventions  can  be  acquired  through 
your  organization's  EDI  coordinator  at  the  start  of  an  EDI  project. 
If  you  find  no  conventions  for  the  business  practice  you  are  about 
to  implement,  your  EDI  coordinator  should  contact  the  DoD  Ex¬ 
ecutive  Agent  for  EDI.  See  Chapter  2.0,  Maintenance,  Section  2.1 
for  the  point  of  contact. 

1.4.2  Documentation  Of  Conventions 

Conventions  are  adopted  from,  and  are  intended  to  be  in  confor¬ 
mance  with,  ANSI  ASC  X12  standards  or  ASC  X12  Draft  Stand¬ 
ards  for  Trial  Use  (DSTU). 

1. 4.2.1  Transaction  Set 

Figure  1.4-1  provides  an  example  of  a  transaction  set  table.  The 
transaction  set  defines  information  of  business  or  strategic  sig¬ 
nificance  and  consists  of  a  transaction  set  header  segment,  one  or 
more  data  segments  in  a  specified  order,  and  a  transaction  set 
trailer  segment.  The  actual  ASC  X12  standard  as  it  appears  in  the 
official  ASC  X12  standards  manual  is  presented  on  the  right  side 
of  the  page.  This  standard  also  includes  both  syntax  notes  and 
comments.  The  specific  DoD  usage  designator  is  presented  on  the 
left  side  of  the  page. 

The  designation  “NAI”  appears  in  the  left  column  if  DoD  does  not 
use  the  specific  segment.  A  page  number  will  tqipear  if  the  segment 
is  used. 

1. 4.2.2  Transaction  Set  Segment 

Figure  1.4-2  is  an  example  of  a  transaction  set  segment. 

DoD  usage  is  specified  on  the  left  side  of  the  page.  For  identifier 
(ID)  —  type  data  elements,  acceptable  code  values  are  listed  on 
the  right  side  of  the  page  under  the  definitions  of  the  element. 

DoD  notes,  reflecting  how  the  convention  is  to  be  used  appear  on 
the  right  side  of  the  page  at  the  segment  level  or  the  data  element 
level. 

The  following  definitions  are  for  use  in  interpreting  the  data 
element  requirement  designators  in  the  DoD-specific  segment 
directory  section  of  the  convention.  For  ASC  X12  usage,  see  the 
definitions  in  XI 2. 6  Application  Control  Structure. 

•  Mandatory 

Mandatory  data  elements  are  defined  by  ASC  X12. 

•  Optional 

Optional  data  elements  are  used  at  the  discretion  of  the  sending 
party  or  are  based  upon  mutual  agreement  between  trading 
partners. 
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824  Application  Advice 

This  standard  provides  the  tormat  and  establishes  the  data  contents  of  the 
Application  Advice  Transaction  Set  (824)  within  the  context  of  an  Electronic 
Data  Interchange  (EDI)  environment.  This  transaction  set  provides  the  ability 
to  report  the  results  of  an  application  system's  data  content  edits  of 
transaction  sets  The  results  of  editing  transaction  sets  can  be  reported  at  the 
functional  group  and  transaction  set  level,  in  either  coded  or  tree-form  format. 
It  is  designed  to  accomodate  the  business  need  of  reporting  the  acceptance, 
rejection  or  acceptance  with  change  of  any  transaction  set.  The  Application 
Advice  should  not  be  used  in  place  of  a  transaction  set  designed  as  a 
specific  response  to  another  transaction  set  (e  g.,  purchase  order 
acknowledgement  sent  in  response  to  a  purchase  order). 
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Figure  1.4-1  Example  of  a  Transaction  Set  Table 
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Required 

Required  data  elements  are  considered  optional  under 
ASC  X12  rules,  but  are  required  by  DoD  decision. 

Recommended 

Recommended  data  elements  are  considered  optional  under 
ASC  X12  rules  and  by  the  DoD,  but  the  industry  recommends 
their  use  to  facilitate  EDI.  Most  companies  in  the  industry 
are  expected  to  use  this  data  element. 

Not  Used 

“Not  Used”  data  elements  are  those  that  the  DoD  does  not 
use. 

Conditional 

Conditional  data  elements  depend  on  the  presence  of  other  data 
elements  in  the  transaction  set. 
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2.0  MAINTENANCE 

■P'is  chapter  describes  the  procedures  for  maintaining  the  DoD 
conventions.  It  also  presents  a  section  on  version/release  timing. 

2.1  ^^\INTAINING  CONVENTIONS 

The  DLA,  as  DoD’s  Executive  Agent  for  EDI  and  PLUS,  has 
established  a  joint  program  office  to  oversee  implementation  of 
EDI.  Some  of  the  functions  of  this  program  office  are  to  maintain 
configuration  control  of  related  standards  and  common  support 
packages  (e.g.,  versions  of  ASC  X12  standards  and  PLUS  algo¬ 
rithms  employed),  participate  in  the  standards-setting  process,  and 
ensure  compliance  with  approved  EDI  standards. 

To  accomplish  these  functions,  the  joint  program  office  has  estab¬ 
lished  a  conventions  and  standards  development  and  maintenance 
process  whose  objectives  are:  (1)  to  obtain  ASC  X12  data  require¬ 
ments  from  the  DoD  Components  and  present  the  requirements  to 
the  ASC  XI2  for  consideration  as  ANSI  standards,  and  (2)  to 
develop  and  maintain  conventions  for  use  by  DoD  Components 
and  their  potential  Tading  partners. 

To  take  advantage  of,  and  not  duplicate,  existing  data  stan¬ 
dardization  processes,  the  £A  has  established  focal  points 
within  the  ASD  Offices,  the  Military  Services,  and  the  Defense 
Agencies  from  which  EDI  information  is  obtained  and  dissemi¬ 
nated. 

The  EA’s  primary  source  of  information  about  DoD’s  data  require¬ 
ments  is  the  EDI  User. 

Changes  to  this  publication  and  recommended  changes  to  ANSI 
ASC  X12  should  be  forwarded  through  your  organizational  point 
of  contact  for  data  standardization  to: 

EDI  Standards  Coordinator 
ATTN:  DLA-ZC 
Cameron  Station 
Alexandria,  VA  22304-6100 

See  Chapter  4  for  reproducible  ASC  X12  Work  Request  forms. 

2.2  VERSION/RELEASE  TIMING 

Identification  of  the  official  “version"  of  a  standard  is  critical  to 
the  successful  interchange  of  information.  Each  panicipant  must 
be  able  to  send  and  receive  the  same  version  to  ensure  the  accuracy 
of  the  information  exchanged. 

The  version  is  transmitted  as  a  12-character  code  in  the  Functional 
Group  Header  segment  (GS)  in  Data  Element  #480.  Ver¬ 
sion/Release/Industry  ID.  This  12-character  code  is  used  by 
ASC  X12  as  follows: 
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Position 

Content 

I -3 

Version  number 

4-5 

Release  level  of  version 

6 

Subrelease 

7-12 

DoD/lndustry  or  Trade  Association  ID 

ASC  X12  assigns  the  codes  in  positions  1  through  6. 

A  major  version  (1-3)  will  change  only  after  an  official  public 
review  cycle,  leading  to  republication  of  a  new  American  National 
Standard. 

Release  level  of  each  ne  c  major  version  (4-6)  will  begin  at  “000” 
and  incremented  by  1  for  each  new  ASC  X12  approved  publication 
cycle,  usually  once  a  year.  The  fifth  character  designates  the 
release  and  the  sixth  character  designates  the  subrelease. 

DoD/Industry/Trade  Association  ID  (7-12)  is  used  to  identify 
conventions.  For  this  suffix,  DoD  will  use  “DoD_”  with  the  10th 
character  identifying  successive  publications.  The  11th  and  12th 
characters  may  be  used  by  the  Military  Departments  or  Defense 
Agencies. 

DoD  conventions  for  using  ASC  X12  standards  are  published 
annually.  Conventions  developed  for  each  release  will  be  main¬ 
tained  for  4  years.  Military  Services  and  DoD  Agencies  will 
determine  which  release  to  use  on  the  basis  of  business  need  but 
will  not  use  any  release  more  than  4  years  old  without  approval 
of  the  DoD  EA. 


2.0.2 
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3.0  DoD  CONVENTIONS  FOR  USING 
ASC  X12  TRANSACTION  SETS 


This  chapter  defines  the  DoD  transaction  set  conventions.  It 
includes  the  instructions  for  implementing  the  control  structure  and 
definitions  of  the  usage  indicators  and  applicable  codes. 

3.1  INTRODUCTION 

The  power  of  the  ASC  X12  standard  is  in  its  building  block 
concept,  which  standardizes  the  essential  elements  of  business 
transactions.  It  is  analogous  to  a  “standard  bill  of  materials  and 
the  construction  specifications,”  which  gives  the  architect 
flexibility  in  what  can  be  designed  with  standardized  materials  and 
procedures.  The  EDI  system  designer,  like  the  architect,  uses  the 
ASC  X12  standards  to  build  business  transactions  that  are  often 
different  because  of  their  function  and  yet  utilize  the  ASC  X12 
standards.  The  “bill  of  materials  and  the  construction  specification” 
of  ASC  X12  are  the  standards  found  in  the  published  technical 
documentation. 

ASC  X12.3  -  The  Data  Element  Dictionary  specifies  the  data 
elements  used  in  the  construction  of  the  segments  that  comprise 
the  transaction  sets  developed  by  ASC  X12. 

ASC  X12.5  -  The  Interchange  Control  Structure  provides  the 
interchange  control  segment  (also  called  an  envelope)  of  a  header 
and  trailer  for  the  electronic  interchange  through  a  data  transmis¬ 
sion;  it  also  provide  a  structure  to  acknowledge  the  receipt  and 
processing  of  the  envelope. 

ASC  X12.6  -  The  Application  Control  Structure  defines  the  basic 
control  structures,  syntax  rules,  and  semantics  of  EDI. 

ASC  X  12.22  -  The  Data  Segment  Directory  provides  the  defini¬ 
tions  and  specifications  of  the  segments  used  in  the  construction 
of  transaction  sets  developed  by  ASC  XI 2. 

The  DoD  convention  in  Section  3.4  conform  to  the  above  standards 
and  each  transaction  set  is  a  complete  document  to  the  extent 
possible.  For  further  clarification  of  acronyms,  abbreviations,  and 
codes,  refer  to  ASC  X12  published  technical  documentation.  Con¬ 
tact  the  DoD  EDI  Executive  Agent  for  copies  or  the  Data  Inter¬ 
change  Standards  Association,  Inc.,  Suite  355,  1800  Diagonal 
Road,  Alexandria,  VA  22314. 

3.2  CONTROL  SEGMENTS 

In  addition  to  the  communication  control  structure,  the  EDI  structure 
provides  the  .standards  user  with  multiple  levels  of  control  to  ensure 
data  integrity.  It  docs  .so  by  using  header  and  trailer  conuol  segments 
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designed  to  identify  uniquely  the  start  and  end  of  the  interchange 
functional  groups  and  transaction  sets.  The  relationship  of  these 
control  segments  is  shown  in  Figure  3.2-1.  Control  Segment 
specifications  are  defined  in  Section  3.2.2. 

3.2.1  Description  of  Use 

The  interchange  header  and  trailer  segments  surround  one  or  more 
functional  groups  or  interchange-related  control  segments  and  per¬ 
form  the  following  functions: 

•  Define  the  data  element  separators  and  data  segment  ter¬ 
minators 

•  Identify  the  sender  and  receiver 

•  Provide  control  information 

•  Allow  for  authorization  and  security  information. 

The  Interchange  Acknolwedgment  Segment  is  used  to  acknowledge 
one  interchange  header  and  trailer  envelope  where  the  envelope 
surrounds  one  or  more  functional  groups.  Q'lo  acknowledgment  is 
made  for  the  interchange  acknowledgment.) 

The  interchange  control  number  value  in  the  acknowledgment 
(TAl  segment)  is  the  same  as  that  for  the  ISA  segment  that  is 
being  acknowledged.  The  control  number  serves  as  a  link  between 
the  interchange  header  and  trailer  and  the  acknowledgment  of  that 
header  and  trailer. 

The  interchange  acknowledgment  does  not  report  any  status  on  the 
functional  groups  contained  in  the  interchange  and  is  separate 
from  the  communication  system’s  error  procedures. 

The  preparer  of  the  interchange  header  and  trailer  indicates  the 
level  of  acknowledgment  in  Data  Element  113,  Acknowledgment 
Requested.  If  an  acknowledgment  is  requested,  then  the  recipient 
must  return  an  acknowledgment.  If  not  requested,  none  should  be 
given. 

The  interchange  acknowledgment  control  segments  are  placed  after 
the  interchange  header  and  before  the  first  function^  group  or 
before  the  interchange  trailer  if  there  are  no  functional  groups. 

Control  segments  are  standard  for  all  implementation  conventions 
produced  for  the  Department  of  Defense.  Some  codes  associated 
with  individual  data  elements  within  the  control  segments  are 
unique  to  the  individual  transaction  set.  Others,  identify  the  ANSI 
version  and  release  in  which  the  convention  is  written. 
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Segment:  ISA  Interchange  Control  Header 

Purpose:  To  start  and  identify  an  interchange  of  one  or  more  functional  groups 
and  interchange-related  control  segments. 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

HBF.  DATA 

PES.  ELEMENT  NAME _ ATTRIDITTES 

ISA01  101  Authorization  information  Qualifier  M  ID  2/2 

Code  to  identify  the  type  of  information  in  the  Authorization  Information. 

00  No  Authorization  Information  Present  (No  Meaningful  Information  in  I02) 

ISA02  102  Authorization  Information  M  AN  10/10 

Information  used  for  additional  identification  or  authorization  of  the  sender  or  the 
data  in  the  interchange.  The  type  of  information  is  set  by  the  Authorization 
Information  Qualifier. 

Implementation  Note: 

If  no  authorization  information  is  agreed  to  by  trading  partners,  fill  field  with  blanks. 

tSA03  103  Security  Information  Qualifier  M  ID  2/2 

Code  to  identify  the  type  of  information  in  the  Security  Information. 

01  Password 

ISA04  104  Security  Information  M  AN  10/10 

This  is  used  for  identifying  the  security  information  about  the  sender  or  the  data 
in  the  interchange.  The  type  of  informatbn  is  set  by  the  Security  Information 
Qualifier. 

Implementation  Note: 

An  agreed  upon  password.  If  no  security  irrformation  is  agreed  to  by  trading  partners,  fill  field  with  blanks. 


ISAOS  105  Interchange  ID  Qualifier  M  ID  2/2 

Qualifier  to  designate  the  system/method  of  code  structure  used  to  designate  the 
sender  or  receiver  10  element  being  qualified. 

ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

An  agreed  upon  desigrtation  ofDoD  Activity  Address  Code  (DoDAAC)  or  other  code  coordinated 
with  the  value-added  network  (VAN). 

ISA06  106  Interchange  Sender  ID  M  ID  15/15 

Identification  code  published  by  the  sender  for  other  parties  to  use  as  the 
receiver  ID  to  route  data  to  them.  The  sender  always  codes  this  number  in  the 
sender  ID  element. 

Implementation  Note: 

DoD  activities  use  Department  of  Defense  Activity  Address  Code  ( DoDAAC )  or  other  code  coordinated  with 
the  value-added  network  (VAN).  Non-DoD  activities  use  identification  code  qualified  by  ISAOS  and 
coordinated  with  the  VAN. 


Mandatory 


ISA07  105  Interchange  ID  Qualifier  M  ID  2/2 

Qualifier  to  designate  the  system/method  of  code  structure  used  to  designate  the 
sender  or  receiver  ID  element  being  qualified. 

ZZ  Mutually  Defined 
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Segment:  GS  Functional  Group  Header 

Purpose:  To  indicate  the  beginning  of  a  functional  group  and  to  provide  control 
information 

Syntax:  The  data  interchange  control  number  (GS06)  in  this  header  must  be 
identical  to  the  same  data  element  in  the  associated  Functional  Group 
Trailer  (GE02). 


Comment:  A  functional  group  of  related  transaction  sets,  within  the  scope  of  X1 2 

standards,  consists  of  a  collection  of  similar  transaction  sets  enclosed  by 
a  functional  group  header  and  a  functional  group  trailer. 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

REF.  DATA 

DES.  ElEMEOT  NAME _ ATTRIRUTES 

GS01  479  Functional  Identifier  Code  M  ID  2/2 

Code  identifying  a  group  of  application  related  Transaction  Sets. 

Implemontation  Note: 

Choose  the  code  value  appropriate  to  the  information  content  of  the  functional  group.  See  XI2  Dictionary  for 
source  code  list. 

AG  Acceptance/Rejection  Advice  (999)  and  Application  Advice  (824) 

GS02  142  Application  Sender’s  Code  M  AN  2/15 

Code  identifying  party  sending  transmission.  Codes  agreed  to  by  trading 
partners. 

Implementation  Note: 

DoD  activities  use  Department  of  Defense  Activity  Address  Code  (DoDAAC).  Non-DoD  activities  use 
identification  code  assigned  by  DoD  activity.  Recommend  for  increased  security  that  non-DoD  code  differ 
from  that  used  in  ISA06. 

GS03  124  Application  Receiver’s  Code  M  AN  2/15 

Code  identifying  party  receiving  transmission.  Codes  agreed  to  by  trading 
partners. 

Implementation  Note: 

DoD  activities  use  Department  of  Defense  Activity  Address  Code  (DoDAAC ).  Non-DoD  act''  dies  use 
identification  code  assigned  by  DoD  activity.  Recommend  for  increased  security  that  non-DoD  code  differ 
from  that  used  in  ISA08. 

GS04  29  Group  Date  M  DT  6/6 

Date  sender  generated  a  functional  group  of  transaction  sets. 

Implementation  Note: 

Assigned  by  translation  software. 

GS05  30  Group  Time  M  TM  4/4 

Time  (HHMM)  when  the  sender  generated  a  functional  group  of  transaction  sets 
(local  time  at  sender’s  location). 

Implementation  Note: 

Assigned  by  translation  software. 


Mandatory 


GS06  28  Group  Control  Number  M  NO  1/9 

Assigned  number  originated  and  maintained  by  the  sender. 
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Segment:  GE  Functional  Group  Trailer 

Purpose:  To  indicate  the  end  of  a  functional  group  and  to  provide  control 
information 


Mandatory 


Syntax:  The  data  interchange  control  number  (GE02)  in  this  trailer  must  be 

identical  to  the  same  data  element  in  the  associated  Functional  Group 
Header  (GS06). 

Comment:  The  use  of  identical  data  Interchange  control  numbers  in  the  associated 
functional  group  header  and  trailer  is  designed  to  maximize  functional 
group  integrity.  The  control  number  is  the  same  as  that  used  in  the 
corresponding  header. 

_ Data  Element  Summary _ 

REP.  DATA 

DES.  ELEMEKT  NAME _ _ ATTRat/TES 

GE01  97  Number  of  Transaction  Sets  Included  M  NO  1/6 

Total  number  of  transaction  sets  included  in  the  functional  group  or  interchange 
(transmission)  group  terminated  by  the  trailer  containing  this  data  element. 

Implementation  Note: 

Assigned  by  translation  software. 


Mandatory 


GE02  28  Group  Control  Number  M  NO  1/9 

Assigned  number  originated  and  maintained  by  the  sender. 

Implementation  Note: 

Assigned  by  the  translation  software.  This  control  number  must  match  the  control  number  of  the  preceding 
GS06  control  number. 
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Segment:  lEA  Interchange  Ckintrol  Trailer 

Purpose:  To  define  the  end  of  an  interchange  of  one  or  more  functional  groups 
and  interchange-related  control  segments. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

MF.  DATA 

DES.  ELEMENT  NAME _ ATTAIDtTTES 

IEA01  116  Number  of  Included  Functional  Groups  M  NO  1/5 

A  count  of  the  number  of  functional  groups  included  in  a  transmission. 

Implementation  Note: 

Assigned  by  translation  software. 

IEA02  112  Interchange  Control  Number  M  NO  9/9 

This  number  uniquely  identifies  the  interchange  data  to  the  sender.  It  is  assigned 
by  the  sender.  Together  with  the  sender  ID  it  uniquely  identifies  the  interchange 
data  to  the  receiver.  It  is  suggested  that  the  sender,  receiver,  and  all  third  parties 
be  able  to  maintain  an  audit  trail  of  interchanges  using  this  number. 

Implementation  Note: 

Assigned  by  the  translation  software.  This  number  must  match  the  number  that  occurs  in  1SA13. 
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ST*824*ABC001  N/L  THIS  IS  AN  824  APPLICATION  ADVICE 

WITH  A  CONTROL  NUMBER  OF 
ABCOOl. 


BGN*  00*AI001*930I15  N/L  THIS  IS  AN  ORIGINAL  APPLICATION 

ADVICE  WHOSE  REFERENCE  NUMBER 
IS  AlOOl.  IT  WAS  PREPARED  ON 
JANUARY  15.  1993. 

N1*FR**33*1B712  N/L  THE  TRANSACTION  IS  FROM  A 

VENDOR  WHOSE  CAGE  CODE  IS  1B712. 

N1*TO**10*N00019  N/L  THE  TRANSACTION  IS  TO  A 

GOVERNMENT  ACTIVITY  WHOSE 
DODAAC  IS  N00019. 

REF*65*A1234  N/L  THE  UNIQUE  TRACKING  NUMBER  OF 

THE  ORIGINAL  TRANSACTION  SET  IS 
A1234. 

PER*IC*JOHN  JONES*TE*7032944260  N/L  THE  VENDOR’S  POINT  OF  CONTACT  IS 

JOHN  JONES  WHOSE  TELEPHONE 
NUMBER  IS  703-294-4260. 

OTI*TR*TN*A123*******836  N/L  THE  ORIGINAL  TRANSACTION  SET  IS 

REJECTED.  IT  HAS  A  TRANSACTION 
REFRENCE  NUMBER  OF  A 1234  AND 
IT  IS  AN  836  CONTRACT  AWARD. 


DTM*097*930126  N/L  THE  836  CONTRACT  AWARD  WAS 

CREATED  ON  JANUARY  26,  1993. 

TED*007*RFQ  NUMBER  MISSING******  SPECIFIES  THE  RFQ  NUMBER  IS 

N0001992Q3010  N/L  MISSING  AND  PROVIDES  THE  NUMBER 

IN  TED08. 

SE*10*ABC001  N/L  THE  TRANSACTION  SET  HAS  10 

SEGMENTS  AND  THE  CONTROL 
NUMBER  IS  ABCOOl. 

NOTE:  ALL  NUMBERS  ARE  NOTIONAL  AND  USED  FOR  ILLUSTRATION  PURPOSES  ONLY. 
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8  070 

9  080 


824  Application  Advice 


This  standard  provides  the  format  and  establishes  the  data  contents  of  the 
Application  Advice  Transaction  Set  (824)  within  the  context  of  an  Electronic 
Data  Interchange  (EDI)  environment.  This  transaction  set  provides  the  ability 
to  report  the  results  of  an  application  system’s  data  content  edits  of 
transaction  sets.  The  results  of  editing  transaction  sets  can  be  reported  at  the 
functional  group  and  transaction  set  level,  in  either  coded  or  free-form  format. 
It  is  designed  to  accomodate  the  business  need  of  reporting  the  acceptance, 
rejection  or  acceptance  with  change  of  any  transaction  set.  The  Application 
Advice  should  not  be  used  in  place  of  a  transaction  set  designed  as  a 
specific  response  to  another  transaction  set  (e.g.,  purchase  order 
acknowledgement  sent  in  response  to  a  purchase  order). 


Table  1 

SEG.ID  NAME 


ST  Transaction  Set  Header 
BGN  Beginning  Segment 

LOOP  ID- N1 

N1  Name 

N2  Additional  Name  Information 

N3  Address  Information 

N4  Geographic  Location 

REF  Reference  Numbers 

PER  Administrative  Communications  Contact 


REaDES.  MAX  USE 


LOOP  REPEAT 


Table  2 


SEG.I0  NAME 


REaOES.  MAX  USE 


LOOP  REPEAT 


LOOP  JD- on 

OTI  Original  T  ransaction  Identification 

REF  Reference  Numbers 

DTM  Date/Time  Reference 

PER  Administrative  Communications  Contact 

AMT  Monetary  Amount 

QTY  Quantity 


LOOP®.  TED 

TED  Technical  Error  Description 

NTE  Note/Special  Instruction _ 

SE  Transaction  Set  Trailer 


tOQOO 


lodoo 
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Mandatory 


Segment: 
Level: 
Loop: 
Usage: 
Max  Use: 
Purpose: 
Syntax: 
Comments: 


BGN  Beginning  Segment 
Header 


Mandatory 

1 

To  indicate  the  beginning  of  a  transaction  set. 

If  BGN05  is  used,  BGN04  is  required. 

f.  BGN02  is  the  Transaction  Set  Reference  Number. 

2.  BGN03  is  the  Transaction  Set  Date. 

3.  BGN04  is  the  Transaction  Set  Time. 

4.  BGN05  is  the  transaction  set  time  qualifier. 


Mandatory 


Mandatory 


Mandatory 


Conditional 


Not  Used 


_ Data  Element  Summary _ 

REF.  DATA 

ots.  ELEMEMT  NM« _ RTramUTES 

BGN01  353  Transaction  Set  Purpose  Code  M  ID  2/2 

Code  identifying  purpose  of  transaction  set. 

00  Original 
01  Cancellation 
04  Change 
12  Not  Processed 

BGN02  127  Reference  Number  M  AN  1/30 

Reference  number  or  identification  number  as  defined  for  a  particular 
Transaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 

BGN03  373  Date  M  DT  6/6 

Date  (YYMMDD). 

BGN04  337  Time  C  TM  4/4 

Time  expressed  in  24-hour  clock  time  (HHMM,  time  range:  0000  though  2359). 

Implementation  Note: 

VseHHMM. 

BGN05  623  Time  Code  O  ID  2/2 
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Segment:  N2  Additional  Name  information 
Level:  Header 


Optional 


Loop:  N1 
Usage:  Optional 
Max  Use:  2 

Purpose:  To  specify  additional  names  or  those  longer  than  35  characters  in  length 


Mandatory 


Optional 


Data  Element  Summary 


REF. 

OES. 

DATA 

ELEMENT 

NAME 

ATTRIDUTES 

N201 

93 

Name 

Free-form  name. 

M 

AN 

1/35 

N202 

93 

Name 

Free-form  name. 

0 

AN 

1/35 
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Optional 


Segment: 
Level: 
Loop: 
Usage: 
Max  Use. 
Purpose: 


N3  Address  Information 

Header 

N1 

Optional 

To  specify  the  location  of  the  named  party 


824  •  APPUCATION  ADVICE 
N3  •  ADDRESS  INFORMATION 


Mandatory 


Optional 


Data  Element  Summary 


REP. 

DES. 

DATA 

ELEMENT 

NAME 

ATTRIBUTES 

N301 

166 

Address  Information 

Address  information 

M 

AN 

1/35 

N302 

166 

Address  Information 

Address  information 

O 

AN 

1/35 
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Optional 


Segment: 
Level: 
Loop: 
Usage: 
Max  Use: 
Purpose: 
Syntax: 


Comments: 


N4  Geographic  Location 

Header 

N1 

Optional 

1 

To  specify  the  geographic  place  of  the  named  party 

1.  At  least  one  of  N401  or  N405  must  be  present. 

2.  If  N401  is  present,  then  N402  is  required. 

3.  If  either  N405  or  N406  is  present,  then  the  other  is  required. 

1.  A  combination  of  either  N401  through  N404  (or  N405  and  N406)  may 
be  adequate  to  specify  a  location. 

2.  N402  is  required  only  if  city  name  (N401 )  is  in  the  USA  or  Canada. 


Conditional 


Conditional 


_ Data  Element  Summary _ 

Mr.  DATA 

D€S.  tLtMtWT  MAMt _ ATTlMDUTia 

N401  19  City  Name  C  AN  2/19 

Free-form  text  for  city  name. 

N402  1S6  State  or  Province  Code  C  ID  2/2 

Code  (Standard  State/Province)  defined  by  appropriate  governmental  agencies. 


Optional 


N403  116  Postal  Code  O  ID  4/9 

Code  defining  international  postal  zone  code  excluding  punctuation  and  blanks 
(zip  code  for  United  States). 

Implementation  Note: 

Use  only  when  the  "party's"  address  has  no  zip  code  but  may  have  another  type  of  postal  code  (e.g.,  in  a 
foreign  courUry). 


Optional 


N404  26  Country  Code  O  ID  2/2 

Code  identifying  the  country. 

Implementation  Note: 

A  translation  table  will  be  required  to  convert  those  standard  codes  used  by  ANSI  to  those  used  by  the  DoD, 
as  corUained  in  DoD  Manual  5000.I2-M. 


NotUaad 
Not  Used 


N405 

309 

Location  Qualifier 

N406 

310 

Location  Identifier 

O  ID  1/2 

C  AN  1/25 
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Segment:  PER  Administrative  Communications  Contact 
Level:  Header 
Loop:  N1 


Optional 


Usage:  Optional 


Max  Use:  3 


Purpose:  To  identify  a  person  or  office  to  whom  administrative  communications 
should  be  directed 


Syntax:  If  PER03  is  present,  then  PER04  is  required. 


Mandatory 


_ Data  Element  Summary _ 

ntf.  DATA 

DCS  CLCUCKT  MAMC  ATmnUTES 


PER01  366  Contact  Function  Code  M  ID  2/2 

Code  identifying  the  major  duty  or  responsibility  of  the  person  or  group  named. 

IC  Information  Contact 


Optional 

PER02 

93  Name 

Free-form  name. 

0 

AN 

1/35 

Optional 

PER03 

365  Communication  Number  Qualifier 

Code  identifying  the  type  of  communication  number. 

O 

ID 

2/2 

Implementation  Note: 

Use  any  code,  although  code  EM  is  preferred. 

EM  Electronic  Mail 

FX  Facsimile 

TE  Telephone 

Conditional 

PER04 

364  Communication  Number  C  AN 

Complete  communications  number  including  country  or  area  code  when 

7/21 

applicable. 


Implementation  Note: 

If  the  communications  number  is  greater  than  21  -haracters,  repeat  the  PER  segment  to  provide  the 
remaining  characters. 
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DA01  •  JANUARY  29  1993 


DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


ANSI  ASC  X12  VERSION/RELEASE  003010DOD_ 


824  •  APPUCATION  ADVICE 
on  >  ORIGINAL  TRANSACTION  IDENnFICAnON 


Mandatory 


Segment:  OTI  Original  Transaction  Identification 
Level:  Detail 

Loop:  OTI  Repeat:  10000 
Usage:  Mandatory 
Max  Use:  1 


Purpose:  To  identify  the  edited  transaction  set,  the  level  at  which  the  results  of  the 
edit  are  reported,  and  to  indicate  the  accepted,  rejected  or  accepted  with 
change  edit  result. 

Syntax:  If  OTI09  is  present,  the  OTI08  is  required. 

Comments:  1.  OTI02  contains  the  qualifier  identifying  the  business  transaction  from 
the  original  business  application,  and  OTI03  will  contain  the  original 
business  application  identification. 

2.  If  used,  OTI04  through  OTI08  will  contain  values  from  the  original 
electronic  functional  group  generated  by  the  sender. 

3.  If  used,  OTI09  through  OTI10  will  contain  values  from  the  original 
electronic  transaction  set  generated  by  the  sender. 

4.  If  OTI1 1  is  present,  it  will  contain  the  Version/Release  under  which  the 
original  electronic  transaction  was  translated  by  the  receiver. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

nCF.  OAT* 

ots.  IUmWT  NAME _ ATTAIOUTtS 

OTI01  110  Application  Acknowledgment  Code  M  ID  1/2 

Code  indicating  the  application  system  edit  results  of  the  business  data. 

TA  Transaction  Set  Accept 
TE  Transaction  Set  Accept  with  Error 
TR  Transaction  Set  Reject 

OTI02  128  Reference  Number  Qualifier  M  ID  2/2 

Code  qualifying  the  Reference  Number. 

Implementation  Notes: 

1.  Use  code  "DX"  to  qualify  an  840  transaction  set  reference  number. 

2.  Use  code  "IV"  to  qualify  an  810  transaction  set  reference  number. 

3.  Use  code  "ME"  to  qualify  an  864  transaction  set  reference  number. 

4.  Use  code  "PR"  to  qualify  an  843  transaction  set  referertce  number. 

5.  Use  code  "SI"  to  qualify  an  856  transaction  set  reference  number. 

6.  Use  code  "TN"  to  qualify  an  824  836,  838,  841, 850 , 855,  860,  and  865  transaction  set  reference  number. 

DX  Department/Agency  Number 
IV  Seller’s  Invoice  Number 
ME  Message  Address  or  ID 
PR  Price  Quote  Number 

SI  Shipper's  Identifying  Number  for  Shipment  (SID) 

TN  Transaction  Reference  Number 


DA01  'JANUARY  29  1993 
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824  •  APPUCATION  ADVICE 

on  •  ORIGINAL  TRANSACTION  IDENnFICATION 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTAnON  CONVENTION 


Mandatory 


Optional 

Optional 

Optional 

Optional 

Conditional 

Optional 

Optional 


Optional 


ANSI  ASC  X12  VERSION/RELEASE  003010DOD_ 

OTI03  127  Reference  Number  M  AN  1/30 

Reference  number  or  identification  number  as  defined  for  a  particular 
Transaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 

Implementation  Notes: 

1.  When  the  OTI02  qualifier  is  code  "DX",  transmit  the  RFQ  number  in  BQT02  of  the  840  transaction  set. 

2.  When  the  OTI02  qualifier  is  code  "IV",  transmit  the  invoice  number  in  BIG02  of  the  810  transaction  set. 

3.  When  the  OTI02  qualifier  is  code  "ME",  transmit  the  number  in  MITOl  of  the  864  transaction  set. 

4.  When  the  OT102  qualifier  is  code  "PR",  transmit  the  price  quote  number  in  REF02  of  the  843  transaction 
set. 

5.  When  the  OT/02  qualifier  is  code  "SI",  transmit  the  number  in  BSN02  of  the  856  transaction  set. 

6.  When  the  OTI02  qualifier  is  code  "TN",  transmit  the  number  in  BGN02  of  the  824  transaction  set;  the 
number  in  BTP02  of  either  the  838(R)  or  838(C}  transaction  sets;  the  nutttber  in  REF02  of  the  84  J 
transaction  set:  or  the  number  in  ST02  of  the  836, 850,  855, 860,  or  865  transaction  sets.  When  transmitting 
the  number  in  ST02,  identify  the  applicable  transaction  set  in  OTIIO. 


OTI04  142 


OTI05  124 


Application  Sender’s  Code  O  AN  2/12 

Code  identifying  party  sending  transmission.  Codes  agreed  to  by  trading 
partners. 

Application  Receiver’s  Code  O  AN  2/12 

Code  identifying  party  receiving  transmission.  Codes  agreed  to  by  trading 
partners. 


OTI06 

OTI07 

OTI08 

OTI09 


29 

30 

28 

329 


Group  Date  O 

Date  sender  generated  a  functional  group  of  transaction  sets. 


DT  6/6 


Group  Time  O  TM  4/4 

Time  (HHMM)  when  the  sender  generated  a  functional  group  of  transactbn  sets 
(local  time  at  sender's  location). 


Group  Control  Number 

Assigned  number  originated  and  maintained  by  the  sender. 


C  NO 


Transaction  Set  Control  Number  O  AN 

Identifying  control  number  assigned  by  the  originator  for  a  transaction  set. 


OTIIO  143  Transaction  Set  Identifier  Code 

Code  uniquely  identifying  a  Transaction  Set. 

Implementation  Note: 

Use  only  to  identify  an  836,  850,  855, 860,  or  865  transaction  set. 


ID 


1/9 


4/9 


3/3 


836  X1 2.54  Contract  Award 

850  X12.1  Purchase  Order 

855  X12.9  Purchase  Order  Acknowledgment 

860  X1 2.1 5  Purchase  Order  Change 

865  X12.16  Purchase  Order  Change  Acknowledgment 


OTI11  480  Version  /  Release  /  Industry  Identifier  Code  O  ID  1/12 

Code  indicating  the  version,  release,  subrelease  and  industry  identifier  of  the  EDI 
standard  being  used.  Positions  1-3,  version  number;  positions  4-6,  release  and 
subrelease  level  of  version;  positions  7-12,  industry  or  trade  association  identifier 
(optionally  assigned  by  user). 


I 
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DA01  'JANUARY  29  1993 


DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


ANSI  ASC  X12  VERSION/RELEASE  003010000 


824  •  APPUCATION  ADVICE 
TED  >  TECHNICAL  ERROR  DESCRIPTION 


Segment:  TED  Technical  Error  Description 
Level:  Detail 


Optional 


Loop:  TED  Repeat:  10000 
Usage:  Optional 
Max  Use:  1 


Purpose:  To  identify  the  error  and,  if  feasible,  the  erroneous  segment,  or  data 
element,  or  both. 

Comment:  If  used,  TED02  will  contain  a  generic  description  of  the  data  in  error 
(e.g..  Part  Number,  Date,  Reference  Number,  etc.). 


Mandatory 


Optional 


Not  Used 
Not  Used 
Not  Used 
Not  Used 
Optional 

Optional 


_ Data  Element  Summary _ 

MF.  OAT* 

DES.  ELEMENT  NAME _ ATTWOUTES 

TE001  647  Application  Error  Condition  Code  M  ID  1/3 

Code  indicating  application  error  conditbn. 

Implementation  Notes: 

1.  Use  any  applicable  code,  although  codes  006  Duplicate,  007  Missing  Data,  and  010  Total  Out  of  Balance 
are  preferred. 

2.  Use  code 722.  to  cover  a  situation  not  explained  by  a  specific  code. 


TED02 

3 

Free  Form  Message 

Free-form  text. 

0 

AN 

1/60 

Implementation  Note: 

Use  for  explanation  pat  'icularly  when  TEDOl  is  code 722. 

TE003 

721 

Segment  ID  Code 

O 

ID 

2/3 

TED04 

719 

Segment  Position  in  Transaction  Set 

o 

NO 

1/6 

TED05 

722 

Element  Position  in  Segment 

0 

NO 

1/2 

TED06 

725 

Data  Element  Reference  Number 

o 

NO 

1/4 

TED07 

724 

Copy  of  Bad  Data  Element 

This  is  a  copy  of  the  data  element  in  error. 

0 

AN 

1/99 

TED08 

961 

Data  Element  New  Content 

New  data  which  has  replaced  erroneous  data. 

0 

AN 

1/99 

Implementation  Note: 

Use  only  when  new  (correct)  data  is  known. 


DAOI  •  JANUARY  29  1993 
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DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


824  •  APPUCAT10N  ADVICE 

NTE  •  NOTeSPECIAL  INSTRUCTION _ ANSI  ASC  X12  VERSION/RELEASE  003010DOD_ 

Segment:  NTE  Note/Speciai  Instruction 
Level:  Detail 


Optional 


Loop:  TED 
Usage:  Optional 
Max  Use:  100 


Purpose:  To  transmit  information  in  a  tree-form  format,  if  necessary,  for  comment 
or  special  instruction 

Comment:  The  NTE  segment  permits  free-form  information/data  which,  under  ANSI 
XI 2  standard  implementations,  is  not  machine  processable.  The  use  of 
the  “NTE”  segment  should  therefore  be  avoided,  if  at  all  possible,  in  an 
automated  environment. 


Optional 


Mandatory 


_ Data  Element  Summary _ 

flKP.  DATA 

OeS.  IL6MEWT  HAMC _ ATHWlITtS 

NTE01  363  Note  Reference  Code  O  ID  3/3 

Code  identifying  the  functional  area  or  purpose  for  which  the  note  applies. 

GEN  Entire  Transaction  Set 

NTE02  3  Free  Form  Message  M  AN  1/60 

Free-form  text. 

Implementation  Note; 

Use  to  provide  details,  e.g.,  vi  Sat  went  wrong  and  what  it  will  take  to  fix  the  problem. 
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DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


ANSI  ASC  X12  VERSION/RELEASE  003010DOD_ 


Mandatory 


Segment:  SE  Transaction  Set  Trailer 
Level:  Detail 

Loop:  _ 

Usage:  Mandatory 
Max  Use;  1 


824  •  APPUCATION  ADVICE 
SE  •  TRANSACTION  SET  TRAILER 


Purpose;  To  indicate  the  end  of  the  transaction  set  and  provide  the  count  of  the 
transmitted  segments  (including  the  beginning  (ST)  and  ending  (SE) 
segments). 

Comment:  SE  is  the  last  segment  of  each  transaction  set. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

REF.  DATA 

OES.  ELEMEMT  NAME _ ATTRaUTES 

SE01  96  Number  of  Included  Segments  M  NO  1/6 

Total  number  of  segments  included  in  a  transaction  set  including  ST  and  SE 
segments. 

SE02  329  Transaction  Set  Control  Number  M  AN  4/9 

identifying  control  number  assigned  by  the  originator  for  a  transaction  set. 

Implementation  Note: 

This  is  the  same  number  as  the  one  in  ST02. 


DA01  •  JANUARY  29  1993 
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DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


4.0  ASC  X  12  FORMS 


In  this  chapter,  applicable  ASC  X12  forms  are  presented. 


BASEUNE  AS  OF:  JANUARY  29, 1993 


DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


DEPARTMENT  OF  DEFENSE 
DRAFT  MPLEHENTATION  CONVENTION 


tlMBMA  SMRMATION  MANUAL 


VIII  -  FORMS,  FORMS,  FORMS 


ASC  X12  Woffc  RtquMt  Fom 

ASC  X12  N«w  Pfojsel  Proposal  Fom 

ASC  X12  Now  Trsnssedon  Sat  Dsvttapmsnt  Form 

Form  (or  Now  or  RsvissP  Appondh  A  Cods  Souroo  Rsforoncs 

OooumoiX  PrsparMion  lor  iisoiprsttlions.  QuUsttnot  and  CofSiol  Standards 

Sampis  Transmital  Form 

ASC  X12  Baloi  Commonl  Rsapenss  Loitsr  Format 
ASC  X12  Standards  Ordsr  Form 


FALL  ISIS 


VIII- 1 


BASELINE  AS  OF:  JANUARY  ».  19S3 


40.3 


Rm.  S/10/90 

DATE  SUBMITTED 


DM  NUMBER 


-  ASC  X12 

WORK  REQUEST  FORM 


(S«er«ttrtat  Only) 


AU.  REQUESTS  MUST  BE  TYPED  or  prinMd  iogibly  In  tXadc  Me.  Complet*  both  sidM. 

1.  TO  USE  THIS  FOAM  FOnSumWTMQ  DATA  maintenance  ran  A  NEW  OMrrSTANOMV  OR  XUMTERPnETATION.  Mai 
raquirafTMittMONEfenn.  if—  | — ^ h  -inimr^  LM Snt •* mw MOmMW. Swn ••  n«w datt (Mamanti/eedM/aed*  tegfOM. 
Than  M  rawMoeM  to  aiMIng  Mgriwrai  and  data  atotnana/eodaa/eoda  aeuieaa.  Than  M  any  odian  (a.g.,  X12.S,  X12.6). 

Z  TO  USE  THIS  FORM  TO  REQUEST  A  CHANGE  TO  AN  E)OSTMQSTANOARO.uaa  a  aaparato  Work  RaduaaiFomi  to  Hal  ad  cnangM  tor 
ana  Mnaacdan  aai  ana  aagmam,  ana  aanaal  ainieaM,  ae  ana  data  atomam.  AH  aaedana  muai  ba  aampMad.  Aitaanmana  may  ba  uaad 
tor  aandnuadan  and  tnauU  ba  numbarad. 


3.  TOUSETHtSFORMrOREauESrAFROROSEONEWXlEFRQjECT.aamptotoSacdanA.  FiOMda  a  putpeaa/aeepa  «id  daaetiba  wiy 
nawtoaturaaln«al«adinSaeitonB.  Fto>ttda  a  aaacHpllan  al  toa  buiiiiaaa  naad  and  jualHieallan  tor  toa  naw  pte|aci  In  Saeban  C/Ptot  X  Tha 
^AtotiiRaqyaanaiabatorwardadtoanaRpiapnaMXHauaaammdtoatoranalyiiaandpraparadanalaptaeaciprepaial. 

CircloOno:  (l)N«wSt«idtRl  Supporting  OatiMaint«nane«  (us*  atlichfiMnts) 

(2)  Existing  Standard  MaMananc*  Raquast  (sa*  Saction  D) 

(3)  Raquast  for  Naw  X12  Projaet 

Acwnyma/abbraiilailana  eannal  ba  addad  to  dia  atondarda.  toduaby  aparWr  tonna  muai  ba  claarty  aiplalnad.  KowWa  Appandii  Aaada 
aauroaratofanaaatoralaitomaSypubiiahadaadalaiaaltod.  lneonipiaMtonnaar*iaaaniaiinadaauatoaupperttor»tocr>anBatoquiatod 
win  ba  raiumad  to  *w  aubrnMiar. 

L  SUBMmrERlNFdRMATlbN 

Subfflittar  Nam*  _ 

Company  _ 

Addraas 

Addrass/ZIP 

Phona  _ 


Indicat*  tha  XI 2  subcommittaa  or  task  group  whosa  position  Is  raprasantsd  hara. 

I  daclara  that  thia  raprasanta  ttia  ofndal  position  of  X12  WORK  GROUP: _ 

astabllshad  at  tha  moating  datad _ 

B.  PROPOSED  WORK:  List  tha  spacMc  changas  to  tha  sundards  baing  raquastad.  GIva  tha  namas  and 
asaociatad  idantMara  of  tha  standards,  sagmanta,  data  aiamants  and  codas  affactad. 


4.0.4 


BASELINE  AS  OP:  JANUARY  2S,  1003 


ocPAimiBrr  or  offBMC 
MtATT  MPLEHENTAnON  OONVflNTION 


PagtTwo 

C.  REASON  FOR  CHANGE: 

Paitl:  Ust  tlw  vwsion/raiMM  of  tfM  fundard  you  am  uainQ  or  using  u  a  ratartnc*.  Nama  tha  tranaaetlon  sal 
that  is  baing/will  ba  uaad  that  dictatas  tha  rsquastad  ^ngad.  List  aifactad  segments  and  data  aiamanu.  or 
other  standards.  Provide  only  rafaranca  numbars/lOs. 

Rafaranea  Seuma  Version  2/Ralaaas _ 

Tranaaetlon  Sal  Used  _ _ 

Sagmant  Attactad  _ _ 

Data  Elemani  Altaetsd _ 

Other  Standard 

Part  II:  Explain  vvhy  you  need  tha  proposad  change.  Provide  a  ccmplata  scenario  that  tals  what  tha  businau 
function,  oparatloa  or  problam  is  that  wd  be  satisfiad  by  a  change  to  tha  sundard.  The  XtZi  Technical 
Assessment  Subcommiitaa  raquiras  enough  Mormation  in  this  Part  II  to  ba  able  to  propose  an  attamata  solubon  t 
nacaaaary. 


0.  RAMIF1CATi6nS:  If  you  drclad  (2)  on  Page  t.GOmplata  this  section.  Toanaurathataltaniiieailonaofyour 
proposed  change  am  recorded  and  that  your  request  Is  eomplato.  drda  below  al  sacdons  of  tha  Mandaids 
affsetad  by  tha  proposed  change. 

TRANSACTION  SET  Hwim  au»aaw/Sooa«  TiSis  WBW/Convwm 


OsMsSaamsM 


SEGMENT 


DbUhMoa 

OHHi  OCPmMou  In  Stgmtm 

rW  QVfVIMnSB  NvW 


DATA  ELEMENT  Nima  Oaiortason  Typa 

Mn/Maa 

CODE  AddaoSa  OataiaCadt  aadaaCada 

OTHER  (a.g..  X12.S.  X12.6): 

ERRORS  NOTED  IN  THE  STANDARD  (GNa  page  na  and  Other  Idantlltcatlon): 


•AMUNE  AS  OP:  JANUARY  ».  ISM 


ooAimiBfr  Of  oeroiic 

Oiurr  MPLEMOfTATION  CONVBfTION 


ftov.  4/1/W 


PP  No. _ 

(Socrttarlat  Only) 


ASCX12 

NEW  PROJECT  PROPOSAL  FORM 

PROCEDURE:  Only  X12  subcomminees  may  us«  this  form  to  register  new  deveiopment  activities  as  X12  project 
proposals  (PPs).  Compieta  all  pagas.  PPs  approved  by  the  Xi2  Procedures  Review  Soard  wn:  be  registered  and 
assigned  a  PP  number  by  OISA,  and  a  Transmittal  Form  wll  be  issued. 

Date  and  complete  the  form  beiow.  Type  or  print  legibly  In  black  ink  and  number  all  attachment  pages 
consecutively.  Submit  to  DISA  prior  to  an  ASC  X12  meeting,  or  to  X12J  Technical  Assessment  Subcommittee 
during  the  subcommittee's  agenda  period  at  an  ASC  X12  meeting. 


Date  Submitted: 

Date  Approved  by  Subcommittee: 

Subcommittee  Name: 

Task  Group  Name/No^: 

Joint  Deveiopmertt  Subcommittee  (H  any): 

Cirele  one:  (a)  Tianuction  Set  (b)  Guideiine  (e)  Other 


Protect  Working  Title: 


Official  Oelegats(s)  tor  This  Project  To  Be  Named  on  Transmittal  Form: 
Name  _ Name 


Company 


Company 


Address 


Address 


Address/ZIP 


Address/ZIP 


Telephone 


Telephone 


BASEUNE  AS  OF:  JANUARY  29, 1993 


ovummiTofomme 

CNUrr  MMiEMCHTATION  CONVBmON 


4l~PURPOSE  ANO  S<^0PE  fOA  THE  PROPOSED  WOMC:  Provtd*  a  purpoM/acop*  for  th« 

prapos«lwort(.  S««Xi2  0MignR«i«and6uid«ilnMtorr*qulr*m«nu. 


B.  EACKGROUMO:  PfpKfcf  6maU  tho  wR  hiipM  in  wvttwing  tfw  pfcpotPl.  Who  af  th«  «p<cted  uMf»? 
How  wfl  ih«  ttandtid  b«  uMtf?  What  buainaM  (Unetton<a)  doM  I  sarvi?.  If  ifia  pfopeaad  Mandard  owadapa  tha 
iwcaonalty  of  an  aadadng  aandaid  or  ona  in  da>/alopman>.  prqwlda  )urtHeadon.  Nthaprapoaallanoiforanaw 
Kandaid  of  puldaMna.  daacriba  tha  protact  In  data!.  (Uaa  adacfanana  >  naeaaaafy.) 


d.  OTHER  STAMbAWOt  IMv6lv1D:  If  acgilcatta.  idanBfy  any  othar  bualnaaa  ltdonnafion  itmdarda  that  ara 
aimiar/raiatad  to  tfia  pfopoail.  and  nama  attndaida  dawaiopan  (a-o-.  ANSI  Aeoadlad  Siandaida  Commdtaaa) 
wtioaa  acttvUaa  may  ba  invofvad  or  iflaciad. 


6.  EXPECTED dOHfCNt/dENClUa. OCSdRIPtlON:  (Of^TIONAL)  ^(jbmttar may «ach a pr«lmliwydraft of 
tnapropoaadatandardoromariupportlngdQcumantation.  DIacuaa  naw  aagmana.  data  alawanta.  coffol 
«nKturaa.andcf«ngaatoXlUorXi2.6tMafafaquiradoranddpatad.  (Uaa  aBacftmanta.) 


•AM UNI  At  OP:  JANUARY  2t.  IPM 


OEPARTIIBfr  OF  DiretSE 

DRAFT  MPLEMENTATION  CONVENTION 


FORM  FOR  NEW  OR  REVtSEO 
APPENDIX  A  CODE  SOURCE  REFERENCE 

INSTRUCTIONS:  Compiete  this  form  whenever  t  new  data  element  or  data  element  code  it  requested  to  be 
added  which  references  a  code  list  published  by  an  external  (non-Xi2)  organization.  Use  one  form  for  each  new 
reference.  This  form  may  be  used  to  revise  current  references;  fill  out  the  appropriate  areas  beiow. 


CIRCLE  ONE,  COMPLETE  AS  APPROPRIATE: 

(1)  NEW  REFERENCE 

(2)  REVISED  REFERENCE,  Current  reference  number/name 


REFERENCE  TITLE:  If  there  is  only  orw  source  for  codes  for  the  dau  element,  the  title  should  be  the  same  as  the 
data  element  name.  If  there  are  miitiple  codes  raferertcing  external  code  sources  for  the  same  data  alemert,  tide 
should  approxifTttte  the  code  definitloa 

REFERENCE  TITLE: 


DATA  ELEMENTS  USED  IN:  Qlve  the  data  element  reference  number  and  name  which  diraeis  the  user  to  this 
Appendix  A  code  source  reference.  Give  the  code  ID  (if  assigned)  If  this  is  for  a  specific  code  of  the  data  alemett. 

USED  IN:  DE  No. _ .  Code  ID _ 


SOURCE:  ProvMe  the  name  of  the  pubileatton  which  contains  the  codes  referenced. 

PUBUSHED  IN: 

AVAILABLE  FROM:  Give  the  publisher,  or  other  contacL  from  whom  the  user  can  obtain  the  document 

Name/Attn  of  _ 

Company  _ 

Address  _ 

Address  _ 

Address/ZlP  _ 

ABSTRACT:  Briefly  describe  the  publication,  its  purpose,  and  Irtdicate  what  codes  It  contains. 
ABSTRACT; 
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oeparhibitof  os^ense 

DRAFT  IMPLEMENTATION  CONVOmON 


DOCUMENT  PREPARATION  FOR 
INTERPRETATIONS,  GUIDEUNES  AND  CONTROL  STANDARDS 


IW.  4/1/90 


Th«M  Instructions  ars  providad  to  assist  davalopars  of  imarprautions.  guidaiinas  and  control  stnjctura  wNcfi  art 
not  transaction  sau  (for  transaction  satt  usa  tha  Naw  Transaction  Sat  Davafopmant  Porm). 

GENERAL:  DISA  providas  tida  paga  and  front  mattar  tor  publications  and  copyadRs  tha  documant  according  to 
DISA  housa  styla. 

REVISIONS:  If  tha  documant  is  a  ravision  of  a  pravtousiy  publishad  Intarpratatlon.  guldaiina  or  staridard.  provida  a 
summary  of  tha  ehangas  to  tha  original  that  art  containad  in  tha  documaia. 

I  INTERPRETATIONS 

A  tomnal  Marpratation  of  an  Standard  is  considarad  part  of  tha  body  of  standards  whan  It  Is  approvad  for 
publication.  Tha  Marpratation  draft  shoiRdstata  tha  issuaprasantad  by  tha  raquastor.stata  tha  propoaad 
Marpratation.  and  show  as  aitaehmataa  any  Work  Raquasts  that  may  ba  nacaaaary  to  affact  tha  Marpratation 
within  tha  subjact  standard.  Tha  draft  Marpratation  is  procaasadUka  any  otharsubcommMaadocumata. 

If  GUIDEUNES 

For  publication  purposas,  guidaiinas  ars  traatad  Oka  a  ioumalarticia.  Basic  raquMmants  ara  givan  balow. 

ABSTRACT:  TMb  la  a  pradsa  summary  of  tha  Purposa/Seopa  (saa  batow).  and  may  ba  idanticai  to  ft  f  that  Is  briaf 
(two  paragraphs);  otharwlaasummartzo  tha  purpoaa/acopa.  It  shotM  contain  anou^Mormation  about  tha 
doeuntant  to  anabla  a  raadar  datamkna  what  tha  guidallna  is  Mandad  to  accomplish  vrfthin  an  EDI  arwlronmart 

PURPOSE  AND  SCOPE:  This  stotamant  must  Mficata  purpoaa  of  tha  guUaHna.  a-g..  tha  buslnaaa  function  or 
oparation  addrassad.  Scops  and  any  spadllc  imitations  of  scopashoiidbadaflnad. 

BOOYOFTEXT:  This  may  ba  a  numbar  of  subaactiona  logicaly  organizad.  Providasactionstortoraword. 
Introduction,  daftmtlon  of  tanna  and  concapts.ra(arancas  and  raiatad  standards.  mathodotogy.spadHcationa. 
raquMmants.  discussion,  and  condusiona,  as  appropriata  to  tha  subjacL 

ART  AND  GRAPHICS:  Graphics  or  artwork  nacassvy  to  Bustrata  tha  documart  ara  ancouragad.  Provfda 
camara-raady  copy  If  thasa  ara  not  aMady  praparad  and  daUvarad  on  a  WP  diskatta  to  DISA. 

FOREWORD,  FOOTNOTES,  APPENDICES:  Thasa  may  ba  usad  for  purpoaas  of  darfty,  Bustration,  or  ganarM 
Monnatlon,notas*partofihaguidallno.'  A  statamara  Indicating  tha  matarial  Is  tor  Monnation  purpoaas  only  and 
not  part  of  tha  gukMIno  shal  appaar  at  tha  bogMiing  of  a  toraword  or  appandbL 

III  CONTROL  STRUCTURES  AND  OTHER  STANDMDS 

For  publication  purpooao,  thasa  documantt  ara  traatad  Ilka  guidaiinas  (saa  Saction  II  abova).  Tha  raquMmanu  ara 
tha  sama.  with  tha  addftion  of  tha  tolowing: 

NEW  SEGMENTS  AND  DATA  ELEMENTS:  Thasa  may  ba  dsfkiad  wfthin  tha  taort;  howawar.  sinea  thay  raprasant 
ehangas  to  X12.22  and  X12.3,  thay  shoiM  ba  spadfiad  on  a  Work  Raquast  Form  attachad  to  tha  draft. 

RELATED  X^2'^  STANDARDS  AND  OTHER  REFERENCES:  Thasa  shal  ba  Idantlllad  In  a  saction  wfthIn  tha  taxL 


BASELINE  AS  OF:  JANUARY  2S,  IStS 


OEPARTMBfT  OF  OTO4SE 

DRAFT  MPLEyENTATION  CONVENTION 


FA0«T«io 

FORMAT;  Draft  SiandRiO  lor  TrW  Um  eonoina  tlw  fonrwt  and  MttbUihM  data  conMnu  ol  itw 

_ Tranaartinn  (  )  lor  uaa  wthln  tha  eoraaa  et  an  Elaaronte  Data  iraacenanga  (EDI) 

anwironmanL  Tha  tranaacdon  aai  (can  ba  uaad  to...)* 


C.  RURR<I)8EAHD^6^  ThiiMtamaramuatlrtfcatathah<lrangaoicaoaMlHaao<thatranaact>onaat.and 
whothaaandara/racairaraara.  Ei^WnthabuainaaalwwtlQnorQparationttiailiaddraaaad.  FdowASCXiE 
Daaign  RUaa  and  GuldaNnaa  and  uaa  Ma  tonnat: 

FORMAT;  Thit  itandaid  piwldaa  tha  temai  and  aatabMahaa  lha  data  contarta  d  lha _ Tranaacdon 

SatwaMnthaeoniaidafanElaetrenicDattiraorchango(EOl)anMiranmanL  TNa  iranoaedon  aat  (can  ba  uaad  to...)* 


6!  TlUMiAfrh6MiETtAilI(8)  faaachtabMpraMdadraloaradngWonwatioa  FORMAT: 

TAILEX 

POSITION  SEGMENT  REQ.  MAX. 

NO.  IP  TITI.E  DES.  USE. 

010  ST  TrafiMction  S«t  Haoddr  M  1 

020  BE  Bdglnning  SdgMnt  For  M  1 

•te. 

Natal:  TMalaanoia.  NOTES ara part d tha itandaid(numbarad). 

CommaniA:  TNa  ia  a  coiwnanL  COMMENTS  art  not  part  d  tha  atandardOaoarad). 


LOOP  REPEAT  NOTE 


Not*  1 
Conant 


^kAM^^tis  faampiaaarauaadtotaattharnaitdthapfepoaadiranaactlonandtoaKpidn 
ona  aKainpia  la  mandaioiy.  No  racoflrdiafala  prapar  nainaa  may  ba  uaad  In  any  awnpia. 


Kio 


FIOUMEl:  (Optional)  Uaa  a  aampMpapardQcumaniualng  mock  data.  V  uaad.  data  muat  ba  aecuraMy  m^pad 
toFiguraZ  OrtsinalsrapMeainuatbaaBBChad(S*i/Ztii*)aottiayeanbaeQpiad. 

FlQUflE2(orEXAMPtJ):  THathaiguraandpraMdaaBualnaaaScanaflotoaidldntotharaadartMtatlaooing 
onmihaaarnpia.  Addihanota:  Tnthjaaaainpta  tha  aatartafcntapraaamadia  data  alainantaaparatcf  and  tha 
N/Leharaetorarapraaantthaaagmaratannlnaior.*  PraaantEDItrananiiaaiondaiaandaarnaanlnglntwocoitfnna. 
aida^-aid*  ZZar22Zeodaaaradlacouragad.alncathalruadtinaaalnanaMpianatonraaaiwplalanl.  FORMAT: 


BUSINESS  SCENARIO:  In  dda  tranaacdon  aat  tha  aondar  la  XYZ  Ratal  Caraar  and  lha  raoaNor  la  thdr  auppllar, 
Fantaadc  Produeia  Mandacturtng  lnc....atc 

EDI  TRANSMISSION  DATA _ fTRANSACTlON  SET  PURPOSE)  DATA 

ST*tXX*0005  N/L  Ba9in  Tranametlon  S«t  tXX;  Control 

No.  0005 

BB*0l*79t00*  N/L  Original  Tranaaisaion;  Raf.  No. 

79t00 

ate. 
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DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


Rm.  S/10/S0 

DMNumbsr _ 

(Spcratvltt  Only) 

OocumsrtNo. _ 

(Davaiopcr  ODttInt  from  OISA) 


ASCX12 

NEW  TRANSACTION  SET  DEVELOPMENT  FORM 

INSTRUCTIONS:  Um  this  form  to  submit  •  drift  trsnsaction  s«t  for  rtviaw  by  Xt2J  TachnicRl  AsMssnwnt  untl  k  Is 
text  processed  by  DISA.  Use  a  new  Transaction  Set  Developmem  Form  whenever  revisions  are  proposed  and  a 
text  fie  has  not  yM  been  prepared  by  OISA. 

ATTACHMENTS:  Attach  al  pages;  use  this  form  as  the  flrsL  Follow  these  instructlona  for  preparing  matarlais. 

The  submkter  must  obtain  a  document  number  assignmeni  from  OISA.  Poet  It  to  this  form  (above). 

Attach  a  Ust  of  Revlalons  If  the  draft  was  previously  reviewed  by  X12J  or  I  this  Is  a  ravised/radesigned 
transaction  sat  standard  requiring  Xt2  baloL 

Use  ONE  Work  Request  Perm  to  list  al  supporting  data  maMenance  for  the  tianaaction  set  and  attach  k 
totMsform.  Propose  new  or  revised  codes  for  OE 143  and  DE  479  at  a  minimum.  I  requirad. 

A  TranamMsI  Form  must  accompany  this  document  when  k  Is  submitted  to  OISA  for  dlatrflMitlon 

Use  the  most  recent  X12^  Standards  Development  Workbook  to  cheek  your  document  for  accuracy. 

iCSUBMIl  TbR  INFORMATidN 

Submitter;  Name  _ _ 

Company  _ _ 

Address  _ _ 

Address/ZiP 


Indicate  the  Xt2  subcommittee  or  task  group  whose  position  Is  represented  here. 
I  declare  that  this  repreaertts  the  offlcial  poaltion  of  X12  WORK  GROUP: 
established  at  the  meeting  dated _ 


B.  ABSTRACT  The  Abstract  Is  registered  with  the  American  National  Standards  Instkuta.  It  is  a  preciae  summary 
of  the  Purpose/Scope  (see  Section  Cbslow).  It  may  be  Identical  to  the  Purpose/Scope  I  tlvt  la  brief  (two 
paragraphs),  otherwise  summarize  the  purpoee/sc^.  it  shotid  contain  enough  mfomwtlon  about  the  standard 
to  enable  a  potential  user  determine  what  equivalent  paper  transaction  k  repreeeras  or  what  the  standard  Is 
Mended  to  do.  Fokcw  the  format  on  page  two. 
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0EPART1IENT  Of  DEFENSE 

DRAFT  MFLEMENTATION  CONVeiTION 


Rm.  S/10/90 

SAMPLE  TRANSMITTAL  FORM 


initiallzsd 

KEY  DATE:  Ftbnisry  IS,  1990 

DELEGATES  NAME 
RESPONSIBLE  SUBCOMMITTEE/TQ# 

TRANSACTION  SET/GUIOEUNE  TITLE 

BALLOT  Document  No. 

Cunent  Document  No. 

Previous  Document  No. 

Project  Proposal  No. 

Associated  WR/DM  No. 


John  Doe 

ASC  X120  XX  SubcommiiteeAG4 
X12J0(  ABC/XYZ  TRANSACTION  SET  (SXX) 


ASCX120/90-051 
ASCX120/9(M)04 
PP*fi60 
DM  012-190 


PROJECT  PROPOSAL 

PP  Review  by  X12J  P^TE)  2/7/90 

PRB  Approves  PP  (DATE)  2/9/90 


DEVELOPMENT  PHASE:  Project  proposal  approval  through  approval  for  X12  vote. 


Document  Submitted  tar  DISA  Tata  Processino  PATE) 

Subcommittee  Approves  Draft  tar  Review  by  XI 2J,  Tech  Aaaesamett  PATE) 

X12J  Tech  Assessment  Review  (DATE) 

PRB  Approves  Document  for  X12  Vote  PATE) 


ORIGINAL  BALLOT  DATA  (DISA): 

Balloi  Closed  Date  PATE) 

Tally/Comments  Sent  to  Chalr/Deieoates  PATE) 

Tally  Stats  (Number  and  Percent) 

_ Ballou  Mated  (100%) 

_ BatouRetumed  ( _ ^%) 

_ Approved  ( _ ^%) 

_ Appw/Comment  ( _ ^%) 

_ Disapproved  ( _ %) 

_ Abstained  ( _ ^%) 


4.e.ia 


BASELINE  AS  OF:  JANUARY  »,  ItSS 


OEPARTMB4TOF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


Pag*  Two 

COMMENT  RESOLUTION  PHASE:  Sm  Sactlons  A.  B  and  C.  If  tha  subcommIRM  It  any  tfina  daddM  to 
lha  documanL  PRB  approval  M  nqiMnct  and  raspons*  laQart  ara  not  nacaaaary. 

A.  COMMENT  RESPONSE  LETTERS:  An  Opan  Forum  muM  ba  schadtiad  at  tha  naxt  X12  maating  following  tha 
baloi  closing  data.  ABthoaawhocommaraadracaivaacommantraiponsalaftarfromthadavaloping 
subcommRtaa.  OlSAraeorda  this  procass  and  handMsthamaling. 

Opan  Forum  Data  (DATE) _ 

RasponsaLattarsMaladOulbyDISA  (DATE) _ 

RabuttalParlodO0dayt)Ck)aaa  (DATE) _ 


ADJUSTED  BALLOT  DATA  piSA): 
3lH>ay  Ratponsa  Ravlaw  Ooaad  Dim 
Taly/Commanis  Sant  to  Chalr/Oalagataa 
TaRy  Stats  (Numbar  and  Paroant) 

_ BaloisMalad  (100%) 

_ BalottRatumad  ( _ ^%) 

_ Approvad  ( _ %) 

_ Appw/Commant  (  %) 

Oliaoofovad  (  %) 

_ Abstamad  ( _ ^%) 


B.  SUBSTANTIVE  REVISION:  If  baloi  commanis  rasiit  In  aubstanOva  ravisionB  to  tba  documart,  tbasa  ira 
ravlawadbyXiSJandprooaasadbyOISA  TharaviMddocumanilsstJbmlttadtoXi2votarsfora30<layiavlaw 
pariod.  OtSAracordstNsptooaas/handMsmMHng.  Subcommittaaa  should  conduct  30^  raviavrt  for  rasponaa 
■attars/ravissd  documanis  ooncurrsntty. 


Subcommlitaa  Approval  of  Ravfaions  (DATE) 

X12J  Ravlaw  of  Ravislons  (DATE) 

DISA  Mats  Ravisad  Documani  (DATE) 

Substantlva  Ravision  OOOay  Ravlaw  Qosas  (DATE) 


(DATE) 

(DATE) 


ADJUSTED  BALLOT  OATApiSA): 

300aySubatani)vaChangaRavlawaosadDats  (DATE) 

Taly/Commanis  Sant  to  Chalr/OalagKas  (DATE) 

TaRy  Stats  (Numbar  and  Paroant) 

_ BaliottMalad  (100%) 

_ Ballou  Ratumad  ( _ ^%) 

_ Approvad  ( _ ^%) 

_ Appw/Commant  ( _ ^%) 

_ Olsapprovad  (  %) 

_ Abstamad  ( _ ^%) 


BASELINE  AS  OF:  JANUARY  ».  ISIS 


4.0.13 


DEPARTMENT  OF  DEFENSE 

DRAFT  SiPCCMENTATION  COMVBfnON _ 

PtgsThrM 

C.  CONTINUING  OBJECTIONS.  If  ther*  are  continuing  disapprovals  after  the  30-day  review  period,  the 
document/disapprovals/responaes/continuing  objections  are  maled  to  X12  members  who  orlginatty  cast  a  ballot, 
for  another  30-day  review,  to  give  them  an  opportwity  to  change  their  vote. 

Continuing  Objections  Maled  to  Chalr/Deiegate  by  OISA 
DISA  Mals  Documents 
30-Oay  Review  Closes 


FINAL  ADJUSTED  TALLY  (OISA):  Whenever  any  disapprovals  are  withdrawn,  a  letter  to  this  effect  must  be 
received  in  writing  by  DISA 

Rnal  Tally  Results  Sent  to  Chair/Delegate  PATE) _ 

30-0ay  Review  Stats  (Adjusted  Tally) 

_ Ballou  Maled  (100%) 

_ Ballou  Returned  ( _ ^%) 

_ Approved  ( _ ^%) 

_ Appw/Commant  ( _ ^%) 

_ Disapproved  ( _ %) 

_ Absuined  ( _ %) 


PRB  APPROVAL  PHASE:  After  the  comment  resolution  period,  the  subcommittee  votes  to  submit  the  document 
to  the  PR6  for  approval  to  publish. 

Subcommittee  Votes  to  Release  to  PRB 
PRB  Approves  Publication 


FOP.  DRAFT  STANDARDS  FOR  TRIAL  USE: 
VERSION/RELEASE/SUBRELEASE  ID  CODE  ASSIGNED: 


PATE) 

(DATE) 


PATE) 

PATE) 

PATE) 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


Pas*  Four 


TfUNSMIlTAL  FORM  imTRUCTIONS: 

GENERAL:  Tbia  TransmiBai  Fonn  M  a  TURNAROUND  DOCUMENT  which  raooida  th*  hMtory/currani  Matua  of  a 
pro)act  documant  It  ia  uaad  to  acehanga  IntormatlQn  batwaan  th*  Sacmartat  and  tha  eornnttaaa  of  X12. 
Infomiailon  la  cumuadv*  (add  on).  This  fonn  la  attachad  to  thadocumantwhanavar  a  la  laauad  tor  distribution  (Rla 
mandatory  for  submitting  doeumanta  to  0lSA.Xi2JTaehnicaiAasaasnianL  and  thaPRB).  Doetanant  corarol 
numbara  ara  aiR  raquirod  on  aaeh  documanL  and  nMv  numbars  ara  raquirad  whanawar  I  la  rawlaad. 

KEY  DATE:  TMalauaadtoldantVythalaiasivaralonofthadoeumant  (dataaaaodatadwththaeunanttiansmlRal 
form  updata). 

DELEGATE:  Each  auboommBaadasignataa  an  lndMduai(daiagBta)  from  th*  group  taaponafcia  for  ihapro|*cL 
Tha  Sacraiariat  muat  ba  Mormad  f  tha  dalagBM  ehangaa. 

INITIATION:  Primary  data  Mraoordad  by  OISA  on  thafeittallzad  form  altar  thaprojactpropoaai  la  approvad  by  tha 
PRB.  Thaaubeommlaa  chair  and  dMagMaN)racaMithaintialttadTianamBal  Form  from  DtSA;tharaaftar.thay 
aiaraaponaMa  for  raoordingthaapproprlaiasuboommlBaa  approval  daiao.  Tha  chalr/datagaw  wE  racaNa  a  copy 
of  tha  updamd  tranamlBal  form  whanovar  I  la  ravlaad  by  DISA. 

UPOATINO:  Ataachapproprtataatap.  DtSAwSPOSTfraahdaatothafonn.  ADOthanaatapproprlatablanicato 
tha  form,  and  SEND  R  to  tha  auboommMsaehair/dalagai*  at  aachatatua  Chang*.  Tha  dafagaMmuat  POST  th* 
form  wRh  fraah  dam  at  aach  aiaiuB  Chang*  for  which  tha  aubcomnUBsa  la  raaponsfel*  and  SEND  I  wth  tha 
appropriat*  documart  to  th*  SocratarlaL 
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OVARTMENT  OF  OffBISE 

Ofurr  MPLEMCNTATION  CONVENTKMI 


ASC  XI 2  BALLOT  COMMENT 
RESPONSE  LETTER  FORMAT 


OeifRAt.  MFOmiATION 

APTtR  AN  Iia  MUjOT.  IMt  RnPONMIU  •UMOHMrmi  (OR  m  OtanNATO  TA«C  onoup)  MUST  fMpond  m  Mttng  »  d 

riiNiwniiN iTiNi  T>»OiyiB«tan4(»wo«rlu>ii wwwuN(OPW)MMM»lyom»noti»quwdaiigond»tWMiMW*wiii<w 

Nirnrwrtnlti  mmirunt  mniyrumi- If  n - r - 1 — TtwOPMMUNawiileDmMniiM^anMmuiitoeoartnMd 

wn  ■«  autaamMOM  ChNr. 


Thirt  Ml  wrn  rwnmai  Nf  hmim  Imm  irtUrTi  in  tfwmn-  >>wrieN»r»WBOwRb>MWiBilMDHwinn.«wd«lnJ>Wiiilwrt 
iMpenMBaKhaoiMiMtar.  3— mtuciont  b#a»idt» 

OmONI;  Oe4ERMLKniR(llAtTIRUTrSI)fOAIXOaiMBnOM 

YouNwypmpiraonalMarNtoMMsaleomnMniDn.  Eiwiy eBnwwntwewwdiiiMNbywawdueidtnyciylNar.  taHCheenaMm 
Iwid. ntwiM flonw—nw (Xta wmbtf aiip<wr«MW>>iidtw««Ni— ididtort—L  LMi jWMpanM •  Im oamMni  Ijmi 
ch«OMWiaptBii.iMM«ii^grqMHi«aBiiwMW«iN><»iiiidg»di»inndiDditw>«gwi».  tiwqr  — wdw  ilupdHuwa  iwwt  b» 


OPnONt:  MOIVRWALlimRTOIAOHOQMM0(TOR 

Youmarpra«M«MlMwtDrM(tieemMnBr.  NyautfioaMMa  addon,  you  nMdiiali«pMid»a(l#i«teamMni(mldM  on  IwbNM. 
PodowdvuMMldMinaaaitMraiyiaandttadamnlltMawtanadala*.  foaty  iiniwdardidtdNaddwwdwuatdaiaodpndBda). 


MmuenoNi 

arvi:  PlanBprimdiadrMdadaaf]iavla«>(a)anARCXUMart«ad.  llyeudBnthan«MMrtiaad.faweanadMnaamafeemdv 
Ranawai  ar  laawduea  9m  lawdta  adaahad,  Yauniairnaiuaada)aanal.aaida>a».arfelar*ladart)aadloryairaB)iMianiinaponaaMaf(a). 

•TVt:  CafftaRaaaOBtaiNradaaumaniaanaalmaiifear.  IMafaaadarnuaiaddaarintRaiNdwf#*  watfiafeaidadaNtvNaar. 
dlWMaandaniwIiiotliddlaifaBrtcawiiianoDf.diadecwtianiaandal  wwbaraaa(dnadlaraia>ailadar«diaa>lBwad>yan‘A* 
(•4..  ASC  Xl2F/Tas«>>iaaA)i  a»  aaeand  ly  a  V  (a-s.  ARC  XiaPn-QMD-iMS).  as. 

STVS:  Chaaia your lador lamis apian (aaa Oanaial  minwislBti abana). 

STIPd:  PrapawdialaaarOalaaandf  auilna. >alOBrMaindatydiaal>Mainaiiladar<ewiM>, 

a  Piw>idaaaBniaHtMma(aandari)tntiaMpparng(iioaiwa>daae«»alaaa»haad:incdidaahBnanuwhor. 
b.  PnmtiodoouHioMeonadlnunbarundartMlodartNddboa 
a  PnMtwdosundartwdooumafdoanaalnunibar. 

d.  XdSaaid>aladarsd»inifclibN(.aflaradanoi<elasslndfadis>adSaaaaalnawdtat(aailna. 
a.  bMhidoanlnaoduaBnrpana'ipRMPwlaauaiaprapodrfdanadodstsadSaaaaa. 
t.  Yogiwayiabsscadf>abadBl1y(baiaywigTtiaiiaMPawti)Nrts  WBwiadanoHsiwdaf. 

STIPi;  ForaaidtialodanStiaSaomartai. AMndonSaorasdoiSonNeoa.aattaoooorladorraquaadnpdMbuiBnaftsiwpanaa 
MH(t|  you  (M«o  prapamL  WliantioladafBtiMbaandaaSuiad.aiadraiaadNogMaandauSeanoniawct«ir«tSioaaNdanisdBSd 
TianamiaN  Pomi  ntaoh  hao  dia  maRrid  data  and  3May  iVMOw  padod  doaaid  das  poaart. 


Sawsla  IndSdual  tador 


0.16 


BASEUNE  AS  OF:  JANUARY  26, 1693 
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Tta  Joattey 
(999)999-9999 


Accredited  Standards  Cdrrvmctee 
ooersting  under  the  orocedures  of  the 
American  NsMmN  Standards  institute 


Document  No 

ASCX12C/TG20/90-999 
Juae  25, 1990 


Daa  SnitAey 
(999)999-9999 


TO:  X12  Meaben  Who  Coaaesied  oa  Modificatioai  to 

X12ja  CoBUol  Structures 

RE:  Respoase  to  Coaaeats  oa  Oeceaber  Ballot 

OMs  205289, 215289, 317289 


Thaak  you  for  your  eoaaeau.  This  ballot  iavohcd  aodifieatioas  to  X12jk  Of  the  327  ballots  Bailed,  153  ballots  were 
returned.  Of  these,  81  approved,  15  approved  with  coaaaat,  20  dbappraecd  with  caaacM  aad  37  abNaiaed. 

la  geaeral,  the  vote  respouses  ivere  ta  favor  of  the  aodifieatioas.  The  aaioricy  of  the  eoaaeau  fooisedoa  the  aapaet 
of  these  aodifieatioas  oa  the  presealatioa  of  iafbraialioa  ia  the  X12.22  Sr  fart  Diteetory.  The  proposed  aodifieatioas 
aad  the  resuhiag  preseatatioa  ia  the  aefauat  dircaory  haw  bcea  rewarfced  a  respoase  to  these  coaaeats.  A  revised 
VIV  tfc»  tnm»  ACT'  vh  ModificatiOBS  tO  the 

docuaea  have  beea  aade  which  reflect  respoaaa  to  the  eoaaeau  froa  this  baDot,  aad  a  revised  copy  of  X12ja  is 
beiag  distribnted  to  all  who  voted  oa  this  asue,  (or  30>day  review  of  revitaoas. 

Specific  respooses  to  coaueau  foOow. 


COMMENT:  Attoaobile  Corporaiioa 

'Add  the  foOowiof  aote  to  ParNpvph  3  J:  NOTE:  r^— protocol  characurs  should  be  ceriudrd  froa  the 
character  sec* 

RESPONSE: 

The  cover  letter  sea  out  with  the  votiag  packafe  eapiaiaed  lha  the  iatea  WM  to  oblaa  coaaeasMB  oa  the  proposed 
aodifieatioas  to  X12jk  X12jb  is  a  diflkuk  staadard  to  aaead.  We  request  tha  ballot  tespoases  be  coetudered  oa  the 
aeriu  of  the  leeaaoMaded  aodifieatioas  aad  aot  oa  the  staadvd  a  a  e4oie.  Yov  coaeaea  was  outside  the  scope  of 
the  requested  aodifieatioas. 
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Fate  Two 


COMMENT;  Aircraft  Corporatioa 

*SoBe  for  Abctract  Syntax  Notation  One  (ASN.l)  ihould  be  alloactL 

1.  ASN.l  ia  of  defiaiaf  all  of  the  neceasary  iater-relationa  needed  by  X12  transactions. 

1  ASN.l  requires  lest  characten  to  define  the  same  information. 

3.  ASN.l  is  the  encoding  scheme  used  by  most  OSI  worL* 

RESPONSE: 

The  recommendation  to  usage  of  ASN.l  encoding  reaches  far  beyond  the  scope  of  the  modifications  requested 

in  this  balloL  Activitiet  such  at  this  are  best  submitted  as  separate  work  requests. 

COMMENT:  Some  Software  Inc. 

‘Conditionality  of  data  elements  should  be  left  to  the  discretion  of  implementation  guidelines  and  agreements.  There  is 
much  ai  tiioes  as  far  as  whether  certain  data  ekmenu  should  be  mandatory  or  not;  many  application  systems 

are  incapable  of  providing  certain  ‘maadatory  information  and,  at  such,  filler'type  data  must  be  inserted.* 

RESPONSE: 

Hm  istue  of  data  element  eonditioaality  as  a  whole  is  a  much  broader  subject  than  was  intended  to  be  addressed  within 
the  scope  of  this  bafloL  This  ballot  was  intended  to  provide  a  meant  for  consisteat  dooimeatatian  and  application  of 
already  existing  conditional  structures.  If  the  commentor  believes  that  the  conditaonnl  structure  should  be  removed  from 
the  standard,  the  task  group  recommendt  that  this  be  submitted  as  a  separate  work  request 


Etc. 
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Accrsdced  Standards  Commtac 

Joe  Somebody 

operstrg  mar  the  procettres  of  ttw 

Chair  TG19.X12C 

Amarcan  Nauaal  Standards  irwututs 

(999)999.9999 

□ocumenc  \a 


ASC  XaCfrGif9M^ 
Auguft  10, 1990 

Ms.  JaaeDoe 
AaerieaaBaak 
Ooe  Ceatrai  PIm 
Middle  Ajaerica,  MO  99999 


RE:  ReapoBK  to  BaQot  Coaaeau  oa 
ASC  X12  Model  Guideiiae 

Dear  Ma.  Doe: 

SahcnaiailteeXUC  baa  eapoaeredkiTaak  Group  19  to  provide  ftipnaaea  to  the  ceea«eataoa  due  balloL  The 
■embers  ofTG19«iih  to  thaakaOXUaeaben  who  took  the  tiaieiiad  effort  to  vouoatkiafaidefii^  We 
especially  thaak  each  iadwidaal  who  provided  cnaaeata,  whether  ia  approval  a  tfaapproval  of  the  fuideBae.  We 
reropiiB  aad  appreciaie  your  careful  review  of  this  docaaeat. 

Our  respoaae  is  keyed  to  the  aaaibfred  keas  ia  the  rnamenti  anarhed  to  your  baOoL 


RESPONSE 

L  We  agree  with  your  oooMeat.  Ia  Sectioa  4,2,2,  we  have  repiaoed  *««  atSn  nila  Mth  *rulca  >  are  utiiaBd*. 

2.  The  coaAauoa  betweea  Seetka  4,13  aad  Secdoa  62  Qidy  eaoatt  because  of  the  eaapie  ew  chose  a  the  first 
sactiouL  This  is  a  hypothetical  caaaple,  of  a  liapliliedaBO^  Headers  aad  iraiksB  caa  be  plaoed  oa  the  coatea  at 
ALL  leeeh,  aad  do  aotaeoessatilycertespead  to  ASC  X12  headers  aad  trailers. 

1  We  apee  with  your  eoaaeat  Intimi  1i  7  hai  tn-m  rhingril  in  that  *thr  rstaMishmriit  nf  *  ~-ai  idilrit  ir  hrar 

lMd4, 
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5.0  GLOSSARY 


This  chapter  contains  ASC  X12  and  DoD  specific  glossaries. 

5.1  XI2  GLOSSARY 

ANSI 

American  National  Standards  Institute 
ANSI  Standard 

A  document  published  by  ANSI  that  has  been  approved  through 
the  consensus  process  of  public  announcement  and  review.  Each 
of  these  standards  must  have  been  developed  by  an  ANSI  commit¬ 
tee  and  must  be  revisited  by  that  committee  within  5  years  for 
update.  See  Draft  Standard  for  Trial  Use  (DSTU). 

Area  Transaction  Set 

Identifies  a  predefined  area  within  a  transaction  set  (header,  detail, 
summary)  containing  segments  and  their  various  attributes. 

ASC  X12 

Accredited  Standards  Committee,  X12  comprises  industry  mem¬ 
bers  who  create  EDI  standards  for  submission  to  ANSI  for  sub¬ 
sequent  approval  and  dissemination;  or  for  submission  to  the 
UN/ECE  for  approval  and  submission  of  UN/EDEFACT  stan-dards. 

Authentication 

A  mechanism  which  allows  the  receiver  of  an  electronic  transmis¬ 
sion  to  verify  the  sender  and  the  integrity  of  the  content  of  the 
transmission  through  the  use  of  an  electronic  “key”  or  algorithm 
which  is  shared  by  the  trading  partners.  This  is  sometimes  referred 
to  as  an  electronic  signature. 

Compliance  Checking 

A  checking  process  that  is  used  to  ensure  that  a  transmission 
complies  with  ANSI  X12  syntax  rules. 

Conditional  (C) 

A  data  element  requirement  designator  which  indicates  that  the 
presence  of  a  specified  data  element  is  dependent  on  the  value  or 
presence  of  other  data  elements  in  the  segment.  The  condition 
must  be  stated  and  must  be  computer  processable. 

Control  Segment 

A  Control  Segment  has  the  same  structure  as  a  Data  Segment  but 
is  used  for  transferring  control  information  for  grouping  data 
segments.  Control  Segments  are  Loop  Control  Segments  (LSA-E). 
Transaction  Set  Control  Segments  (ST/SE),  and  Functional  Group 
Control  Segments  (GS/GE).  defined  in  X12.6.  and  Interchange 
Control  Segments  (ISA/DEA/TAl)  defined  in  X12.5. 
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Data  Element 

The  basic  units  of  information  in  the  EDI  standards  containing  a 
set  of  values  that  represent  a  singular  fact.  They  may  be  single¬ 
character  codes,  literal  descriptions,  or  numeric  values. 

Data  Element  Length 

This  is  the  range,  minimum  to  maximum,  of  the  number  of  char¬ 
acter  positions  available  to  represent  the  value  of  a  data  element. 
A  data  element  may  be  of  variable  length  with  range  from  mini¬ 
mum  to  maximum,  or  it  may  be  of  fixed  length  in  which  the 
minimum  is  equal  to  the  maximum. 

Data  Element  Reference  Number 

Reference  number  assigned  to  each  data  element  as  a  unique 
identifier. 

Data  Element  Requirement  Designator 
A  code  defining  the  need  for  a  data  element  value  to  appear  in  the 
segment  if  the  segment  is  transmitted.  The  X12  codes  are  man¬ 
datory  (M),  optional  (O),  or  conditional  (C).  DoD  may  "require" 
a  segment  which  is  optional  by  X12  standards. 

Data  Element  Separator 

A  unique  character  preceding  each  data  element  that  is  used  to 
delimit  data  elements  within  a  segment.  Dod  uses  as  the 
delimiter. 

Data  Element  Type 

A  data  element  may  be  one  of  six  types:  numeric,  decimal, 
identifier,  string,  date,  or  time. 

Delimiters 

The  delimiters  consist  of  two  levels  of  separators  and  a  terminator. 
The  delimiters  are  an  integral  part  of  the  transferred  data  stream. 
Delimiters  are  specified  in  the  interchange  header  and  may  not  be 
used  in  a  data  element  value  elsewhere  in  the  interchange.  From 
highest  to  lowest  level,  the  separators  and  terminator  are  segment 
terminator  and  data  element  separator. 

DISA 

Data  Interchange  Standards  Association.  A  nonprofit  organization 
funded  by  ASC  X12  members  which  serves  as  the  Secretariat  for 
X12. 

DSTU 

Draft  Standard  for  Trial  Use.  Represents  a  document  approved  for 
publication  by  the  full  X12  committee  following  membership  con¬ 
sensus  Mid  subsequent  resolution  of  negative  votes.  (Final  Report 
of  X12  Publications  Task  Group).  The  Draft  EDI  Standard  for 
Trial  Use  document  represents  an  ASC  X12  approved  standard  for 
use  prior  to  approval  by  ANSI.  See  ANSI  Standard. 
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EDI 

Electronic  Data  Interchange.  The  computer  application  to  com¬ 
puter  application  exchange  of  business  information  in  a  standard 
format. 

Electronic  Envelope 

Electronic  information  which  binds  together  a  set  of  transmitted 
documents  being  sent  from  one  sender  to  one  receiver. 

Element  Delimiter 

A  single-character  which  follows  the  segment  identifier  and 
separates  each  data  element  in  a  segment  except  the  last. 

Functional  Group 

A  group  of  one  or  more  transaction  sets  bounded  by  a  functional 
group  header  segment  and  a  functional  group  trailer  segment. 

Functional  Group  Segments 

GS/GE  segments  identify  a  specific  functional  group  of  documents 
such  as  purchase  orders. 

Industry  Conventions 

Defines  how  the  ASC  X12  standards  are  used  by  the  specific 
industry 

Industry  Guidelines 

Defines  the  EDI  environment  for  using  conventions  within  an 
industry.  It  provides  assistance  on  how  to  implement  X12  stand¬ 
ards. 

Interchange  Control  Segments 

ISA/IEA  segments  identify  a  unique  interchange  being  sent  from 
one  sender  to  one  receiver  (see  electronic  envelope). 

Interchange  Control  Structure 

The  interchange  header  and  trailer  segments  envelop  one  or  more 
functional  groups  or  interchange-related  control  segments  and  per¬ 
form  the  following  functions:  (1)  defines  the  data  element 
separators  and  the  data  segment  terminators,  (2)  identifies  the 
sender  and  receiver,  (3)  provides  control  infonnation  for  the  inter¬ 
change,  and  (4)  allows  for  authorization  and  security  information. 
(XI  2.5) 

Loop 

A  group  of  semantically  related  segments;  these  segments  may  be 
either  bounded  or  unbounded  (X12.6).  The  N1  loop  is  an  example 
of  a  loop,  which  includes  segments  N1  to  PER  for  name  and 
address  information. 

Mandatory  (M) 

A  data  element/segment  requirement  designator  which  indicates 
the  presence  of  a  specified  data  element  is  required. 
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Mapping 

The  process  of  identifying  the  standard  data  element’s  relationship 
to  application  data  elements. 

Max  Use 

Specifies  the  maximum  number  of  times  a  segment  can  be  used  at 
the  location  in  a  transaction  set 

Message 

Entire  data  stream  including  the  outer  envelope 
Optional  (O) 

A  data  element/segment  requirement  designator  which  indicates 
the  presence  of  a  specified  data  element/segment  is  at  the  option 
of  the  sending  party  which  can  be  based  on  the  mutual  agreement 
of  the  interchange  parties. 

Qualifier 

A  data  element  which  identifies  or  defines  a  related  element,  set 
of  elements,  or  a  segment.  The  qualifier  contains  a  code  taken 
from  a  list  of  approved  codes. 

Repeating  Segment 

A  segment  that  may  be  used  more  than  once  at  a  given  location 
in  a  transaction  set.  See  Max  Use. 

Security 

System  screening  which  denies  access  to  unauthorized  users  and 
protects  data  from  unauthorized  uses 

Segment 

Segments  consist  of  logically  related  data  elements  in  a  defined 
sequence.  A  data  segment  consists  of  a  segment  identifier,  one  or 
more  data  elements  each  preceded  by  an  element  separator,  and 
ends  with  a  segment  terminator. 

Segment  Directory 

Provides  the  purpose  and  format  of  the  segments  used  in  the 
construction  of  transaction  sets.  The  directory  lists  each  segment 
by  name,  purpose,  identifier,  the  contained  data  elements  in  the 
specified  order,  and  the  requirement  designator  for  each  data 
element. 

Segment  Identifier 

A  unique  identifier  for  a  segment  composed  of  a  combination  of 
two  or  three  upper-case  letters  and  digits.  The  segment  identifier 
occupies  the  first-character  positions  of  the  segment.  The  segment 
identifier  is  not  a  data  element.  The  segment  identifier  in 
EDIFACT  is  a  component  data  element  —  part  of  a  composite 
data  element  consisting  of  a  segment  identifier  and  an  explicit 
looping  designator. 
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Segment  Terminator 

A  unique  character  appearing  at  the  end  of  a  segment  to  indicate 
the  termination  of  the  segment,  e.g.,  N/L. 

Syntax 

The  grammar  or  rules  which  define  the  structure  of  the  EDI 
standards  (i.e.,  the  use  of  loops,  qualifiers,  etc.).  Syntax  rules  are 
published  in  ANSI  XI  2.6. 

Transaction  Set 

The  transaction  set  unambiguously  defines,  in  the  standard  syntax, 
information  of  business  or  strategic  significance  and  consists  of  a 
transaction  set  header  segment,  one  or  more  data  segments  in  a 
specified  order,  and  a  transaction  set  trailer  segment. 

Transaction  Set  ID 

An  identifier  that  uniquely  identifies  the  transaction  set.  This 
identifier  is  the  flrst  data  element  of  the  transaction  set  header 
segment. 

Transladon 

The  act  of  accepting  documents  in  other  than  standard  format  and 
translating  them  to  the  standard. 

Version/Release 

Identifies  the  publication  of  the  standard  being  used  for  the  genera¬ 
tion  or  the  inteipretation  of  data  in  the  X12  standard  format.  May 
be  found  in  the  Functional  Group  Header  Segment  (GS)  and  in  the 
Interchange  Control  Header  Segment  (ISA).  See  Control  Segment. 

Vies  Committee 

Voluntary  Interindustry  Communications  Standards  for  Electronic 
Data  Interchange 

X12 

The  ANSI  committee  responsible  for  the  development  and  main¬ 
tenance  of  standards  for  electronic  data  interchange  (EDI). 

X12,5 

Interchange  Control  Structure.  This  standard  provides  the  inter¬ 
change  envelope  of  a  header  and  trailer  for  the  electronic  inter¬ 
change  through  a  data  transmission,  and  it  provides  a  structure  to 
acknowledge  the  receipt  and  processing  of  this  envelope. 

X12.<> 

Application  Control  Structure.  This  standard  describes  the  control 
segments  used  to  envelop  loops  of  data  segments,  to  envelop 
transaction  sets,  and  to  envelop  groups  of  related  transaction  sets. 
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5.2  DoD  GLOSSARY 

AIS 

Automated  Information  Systems 
ASD(P&L) 

Assistant  Secretary  of  Defense  (Production  and  Logistics) 

DES 

Data  Encryption  Standard 
DISA 

Defense  Information  Systems  Agency 
DLA 

Defense  Logistics  Agency 
ISA 

Interchange  Control  Header  Identifier 
NIST 

National  Institute  of  Standards  and  Technology 
NTE 

Note  Identifier 
PLUS 

Protection  of  Logistics  Unclassified/Sensitive  Systems 
UN/EDIFACT 

EDIFACT;  Electronic  Data  Interchange  for  Administration,  Com¬ 
merce,  and  Transport 
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